RE: Enlightenment via avoiding the T-word

[Nicolas LEHUEN <nicolas.lehuen@ubicco.com>]

>-----Message d'origine-----
>De : Kian-Tat Lim [mailto:ktl@ktlim.com]
>Envoye : mardi 28 aout 2001 10:57
>A : 'xml-dev@lists.xml.org'
>Objet : Re: Enlightenment via avoiding the T-word
>
>
>Nicolas LEHUEN wrote:
>> <purchase xmlns="http://foobar/purchase">
>>         <customer>
>>                 <name>Nicolas</name>
>>                 <address>Paris, France</address>
>>         </customer>
>>         <delivery>
>>                 <mode>UPS</mode>
>>                 <address>Somewhere else</address>
>>         </delivery>
>>         <lines>
>>                 <line>
>>                         <!-- duh, will this wake up Echelon :) ? -->
>>                         <product>
>>                                 <name>ACME Explosives</name>
>>                                 <price currency="dollar">2000</price>
>>                         </product>
>>                         <quantity>200</quantity>
>>                 </line>
>>         </lines>
>> </purchase>
>
>The "overloadings" here are <address> and <name>.
>
><address> is not a problem.  Both of the addresses are, in fact,
>addresses, with no syntactic or semantic difference.  But wait,
>you argue -- the delivery address must be treated differently than
>the customer address.  I would claim that the <customer> element
>should be treated differently than the <delivery> element; the
><address> elements, for software that only understands those, do
>not need to be treated differently.
>
><name> is another issue.  It is probable that names of people should
>be handled differently than names of products (semantic difference),
>and they will typically have syntactic differences as well.  I would
>argue that one or both should be renamed to make this distinction
>clear: <personalName> (as opposed to a possible <companyName>) and/or
><productName>.
>
>Why have a context at all if names are prefixed (or otherwise modified)
>based on their context?  Simply for encapsulation and 
>modularity, exactly
>as Nicolas argues.  The fact of structure is still useful even if the
>(mere) syntactic sugar of shortening names based on context is 
>not present.
>Java packages would still be useful even if there were no abbreviation
>facility.
>
>Nicolas believes using multiple namespaces as a way of providing
>extensibility is flawed.  I would argue that this is a defect in
>the available tools.  There is nothing conceptually, or even
>practically, difficult about using multiple namespaces in a
>well-formed XML document.  There is no price to pay for building
>new namespaces if existing, published, micro-reusable elements
>can be employed.  After all, namespaces are simply more syntactic
>sugar for abbreviating universally-unique names.
>
>Nicolas also argues that XSLT can handle context-sensitive naming,
>so it is likely that other processing systems will be able to do
>so as well.  I claim that this is so only within a restricted domain
>where structures are predefined and immutable.  For example, let us
>say that we want to write an XSLT transform that will modify every
>mailing address, and only mailing addresses, in a set of *arbitrary*
>documents.  If the documents use context-sensitive names, a list of
>all possible contexts for mailing addresses will have to be provided
>to the transform.  If the documents use globally meaningful names,
>a much smaller list of the names corresponding to mailing addresses
>(potentially even as small as one name) is all that would need to be
>provided.
>
>It can be argued that this use case is spurious, but context-sensitive
>names fundamentally are more difficult to deal with, because all
>processing must be context-sensitive at some level.  (It's possible
>to confine all the context-sensitive processing to one level, if that
>level transforms all such names into non-context-sensitive ones, like
>NUNs.)
>
>-- 
>Kian-Tat Lim, ktl@ktlim.com, UTF-7: +Z5de+pBU-
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.xml.org/ob/adm.pl>
>