RE: Enlightenment via avoiding the T-word

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

Well I wouldn't be surprised that by adhering to the "all-global" policy, we
would soon find our namespaces too small... Let's consider this (somewhat
corny) "purchase" sample with local elements :

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

How should I remove the local names ? By giving each context (customer,
delivery or product) a dedicated namespace ? Or just by ensuring that each
label has a unique name within the namespace ? In the first case, I'm not
making things more simple, because I'm directly entering the domain of
multiple-namespace schemas. Now, let's examine the second case :

<purchase xmlns="http://foobar/purchase">
	<customer>
		<customerName>Nicolas</customerName>
		<customerAddress>Paris, France</customerAddress>
	</customer>
	<delivery>
		<mode>UPS</mode>
		<deliveryAddress>Somewhere else</deliveryAddress>
	</delivery>
	<lines>
		<line>
			<product>
				<productName>ACME Explosives</productName>
				<price currency="dollar">2000</price>
			</product>
			<quantity>200</quantity>
		</line>
	</lines>
</purchase>

Now, I have two remarks :

1) If I have to prefix all my label based on their context (e.g.
customer/name => customerName), why have a context at all ? I could drop my
document structure and have something like that :

<purchase xmlns="http://foobar/purchase">
	<customerName>Nicolas</customerName>
	<customerAddress>Paris, France</customerAddress>
	<mode>UPS</mode>
	<deliveryAddress>Somewhere else</deliveryAddress>
	<line>
		<lineProductName>ACME Explosives</productName>
		<lineProductPrice currency="dollar">2000</price>
		<lineQuantity>200</lineQuantity>
	</line>
</purchase>

I could achieve something worse by just dropping the "line" tag, and what
would I get ? A table ! If I put structure (and therefore, context) in my
XML documents, it is to achieve modularity (of documents, schemas,
stylesheets or processing programs). If I needed tables, I would not have
chosen XML in the first place.

2) Suppose now that I want to extend my purchase schema by adding the
following "payment" element :

<payment>
	<mode>cash</mode>
	<date>20010828T1133Z</date>
</payment>

The "mode" label is already used, because I didn't find it interesting to
rename the delivery/mode to "deliveryMode" when I first designed the
purchase schema (OK here it could have thought about it, but this could
happen in more complex schemata). So now, I have to rename payment/mode to
paymentMode, and I have an unbalanced schema where the delivery/mode gets to
have an "unqualified" label, giving it a kind of precedence on payment/mode.

I think renaming local elements to make them global, based on their context,
is therefore a bad idea. Problem is, the only way to have both global
element names only AND achieve modularity and extensibility is to
extensively use namespaces, like this :

<purchase xmlns="http://foobar/purchase">
	<customer xmlns="http://foobar/customer">
		<name>Nicolas</name>
		<address>Paris, France</address>
	</customer>
	<delivery xmlns="http://foobar/delivery">
		<mode>UPS</mode>
		<address>Somewhere else</address>
	</delivery>
	<lines>
		<line>
			<!-- duh, will this wake up Echelon :) ? -->
			<product xmlns="http://foobar/product">
				<name>ACME Explosives</name>
				<price currency="dollar">2000</price>
			</product>
			<quantity>200</quantity>
		</line>
	</lines>
</purchase>

The problems with this approach are :

1) XML Schema get complex and will put pressure on my tool set.
2) I'll have to build a namespace each time a new context appear (e.g. if I
add the payment element). Instead of handling a single document, I'll hav to
handle a document PLUS a mess of namespaces. This does not make things more
easy.

The real question is : do we need the injection ulabel => meaning described
by Matthew ? Depending on your programming model, it's not certain. In XSLT,
for example, context-sensitive content model do not pose any problem. In
other programming model, I think, like Michael, that provided that we are
given some good PSVI, we do not need the aforementionned injection.

Regards,
Nicolas

	
>-----Message d'origine-----
>De : Rick Jelliffe [mailto:ricko@allette.com.au]
>Envoyé : mardi 28 août 2001 04:57
>À : xml-dev@lists.xml.org
>Objet : Re: Enlightenment via avoiding the T-word
>
>
> From: "Fuchs, Matthew" matthew.fuchs@commerceone.com
>
> > To start, people might actually try working with XSDL local 
>types before
>> voting.  I realize that's not necessarily the American Way, 
>but it might
>> help. 
>
>I would recommend the opposite: that people avoid local names 
>like the plague
>for any public or non-experimental schemas.  
>
>Don't give different things the same name. If you have two people who
>want to use the same name, get them to duke it out or allocate 
>different
>namespaces.  The idea that it is more readable to have equivocal names
>is bogus. 
>
>The least good reason for an XML schema language to support something
>is that it makes large queries easy, or that it fits in with 
>one particular
>programming language. Carts before horses: an XML Schema language
>should support and encourage good XML documents and good markup 
>practise.
> 
>How should it be? Here's how I see it:
>
>1) The basic semantics of an element or attribute should be 
>given by its name;
>for any namespace the general semantics of a name should not change.
>So a <line> should always be a drawn thing; or always a text 
>line; or always
>a joke, but never one thing in one context and another thing 
>in another context
>within the same namespace or locally.
>
>  1a) Attributes are local names, but their semantics should 
>not be local to the
>  element, but global to the namespace of the elements to 
>which they adhere:
>  an *:*/@dog should have the same basic semantics.
> 
>  1b) An element with a local names with different basic 
>semantics is an innovation 
>  of practise which is bloating incrementalism to support, and 
>we would be 
>  better to be rid of it.  
>
>2) The specific content model and allowed attributes of an element
>may change utterly according to other markup. 
>
>  2a) However, parent context is not enough to model well the kinds
>  of constraints found in real situation.
>
>  2b) There is a feeling from some that the separation of 
>static schemas
>  (for storage) and dynamic schemas (e.g. Schematron and co-occurrence
>  constraint schemas or business rules schemas) is useful.
>
>There should be no requirement to support bad markup. Elements with
>different basic semantics but the same name is bad markup.  
>There should
>be no requirement to support solutions that don't make anywhere near
>60/40, let alone 80/20.  IMHO the limited context provided by 
>XML Schemas
>do not meet the minimum mark. Furthermore, since they encourage the
>use of elements where attributes would be more appropriate, it can
>positively discourage good markup.
>
>Cheers
>Rick Jelliffe 
>
>
>-----------------------------------------------------------------
>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>
>