RE: Enlightenment via avoiding the T-word

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

Ooops, sorry for the previous empty mail.

><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.

OK I get it. In fact, what you advocate here is to use context-sensitive
processing of global elements ; adress could be a global element, but you
would use it for charging or shipping depending on the enclosing global
elements.

>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.

Actually, we agree on this point : I do believe the namespace option is the
best one, but apart from the tool problem, I think replacing context
sensitivity by namespaces is not going to make things any simpler nor work
at all. In the solutions you presented above (for address and name), you
don't remove the context sensitivity : it is removed from elements names,
but not from element interpretation, especially for address. So my position
here is that you can't do without context sensitivity, but still use
namespace to obtain unique global names (that's what a namespace is made
for, anyway).

>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.

If you have only one name for a mailing adress content model, then you'll
rely on context sensitivity to know what to do with the various addresses
you encounter (even in presentation, you don't handle shipping and billing
address the same way on a bill). We DO need context-sensitivity for content.
Removing it from names won't remove it from the semantic meaning of the
document.

>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.)

What I wanted to show in my previous mail is that writing structured content
in an XML document is a way to answer our needs for context sensitivity. If
we didn't needed it, we would not have to write structured content, and
simple CSV files would suffice. Contrary to you, I think that
context-independant processing of structured data is VERY rare. We all have
been writing programs manipulating structures or object for decades now. Try
to remember when you last wrote a program that would handle separate pieces
of data independantly, for example without taking care of where this Address
instance is coming from - the billing field or the shipping field of my
Order instance ?

Regards,
Nicolas

>-- 
>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>
>