[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Enlightenment via avoiding the T-word

• From: Kian-Tat Lim <ktl@k...>
• To: "'xml-dev@l...'" <xml-dev@l...>
• Date: Tue, 28 Aug 2001 01:57:04 -0700

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@k..., UTF-7: +Z5de+pBU-

• References:
  • RE: Enlightenment via avoiding the T-word
    • From: Nicolas LEHUEN <nicolas.lehuen@u...>

• Prev by Date: RE: Enlightenment via avoiding the T-word
• Next by Date: RE: Enlightenment via avoiding the T-word
• Previous by thread: RE: Enlightenment via avoiding the T-word
• Next by thread: Re: Enlightenment via avoiding the T-word
• Index(es):
  • Date
  • Thread