Re: Enlightenment via avoiding the T-word

[Rick Jelliffe <ricko@allette.com.au>]

 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