On 2/1/07, <b class="gmail_sendername">Stephen Paul Weber</b> &lt;<a href="mailto:singpolyma@gmail.com">singpolyma@gmail.com</a>&gt; wrote:<div><span class="gmail_quote"></span>&gt;On 2/1/07, Dick Hardt &lt;<a href="mailto:dick@sxip.com">
dick@sxip.com</a>&gt; wrote:<br>&gt;&gt; All of these formats are limiting Chris.<br>&gt;Not really... If you want more you expand them.&nbsp;&nbsp;It&#39;s not<br>&gt; hard to extend uF stuff with either namespacing, extra<br>&gt; classes, XOXO, or some other method.
<br><br>I think that the limitation that Dick was referring to is not a limitation in the ability to extend what you can encode using any of the formats you mention, rather, the limitation is related to the ease with which data in these formats is exchanged with systems that use data written in other formats. The formats that you mention are all of a class that might be called &quot;self-centered.&quot; They are only concerned with what they can or cannot express. The problem addressed by Attribute Exchange is, however, the problem of *exchange*. Thus, you need formats which take into account the requirements of exchange, not just those concerning expressiveness. What happens in the &quot;less-limited&quot; formats that Dick is talking about is that individual attributes are identified using a IRI or URI rather than by some schema specific name. The use of more granular definitions as well as a globally useful naming system makes it vastly easier to do, and reason about doing, exchange between applications.
<br><br>bob wyman<br><br></div>