[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Enlightenment via avoiding the T-word
- From: Nicolas LEHUEN <firstname.lastname@example.org>
- To: 'Rick Jelliffe' <email@example.com>,"'firstname.lastname@example.org'" <email@example.com>
- Date: Tue, 28 Aug 2001 10:10:34 +0200
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 :
<!-- duh, will this wake up Echelon :) ? -->
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 :
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 :
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 :
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 :
<!-- duh, will this wake up Echelon :) ? -->
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
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.
>De : Rick Jelliffe [mailto:firstname.lastname@example.org]
>Envoyé : mardi 28 août 2001 04:57
>À : email@example.com
>Objet : Re: Enlightenment via avoiding the T-word
> From: "Fuchs, Matthew" firstname.lastname@example.org
> > To start, people might actually try working with XSDL local
>> voting. I realize that's not necessarily the American Way,
>but it might
>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
>namespaces. The idea that it is more readable to have equivocal names
>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
>programming language. Carts before horses: an XML Schema language
>should support and encourage good XML documents and good markup
>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
> (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.
>be no requirement to support solutions that don't make anywhere near
>60/40, let alone 80/20. IMHO the limited context provided by
>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.
>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