Re: Namespaces, schemas, Simon's filters.

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

 From: "Tim Bray" <tbray@textuality.com>
 

> At 04:41 PM 20/08/01 -0700, Fuchs, Matthew wrote:
> >So, to contrive an example beyond foo and bar (with the obvious danger that
> >people will spend their time trying to pick apart the example, rather than
> >use it to understand the goal), suppose I want to create a Schema to
> >coordinate graphics, music, and text.  So I create a <graphic> element, a
> ><music> element, and a <text> element and I have three different people
> >working on designing each of these elements.  Now, my graphics designer
> >decides he wants to have a <line> element to describe lines that will be
> >drawn.  Similarly, my musician decides he wants a <line> element to describe
> >a line of music (perhaps strophe would be better, but then perhaps I've
> >chosen one as ignorant of the subject matter as myself).  And, of course, my
> >writer also wants a <line> element 
> 
> OK, I think I get it.  Local element types allow the <line>
> element to have different validation rules depending on 
> whether it's a child of <matt:music>, <matt:graphics> or 
> <matt:text>.  Clearly something that DTD's can't do but is 
> desirable.
 
But is it a superficial usefulness?

If they are separate lines semantically, why not put them
into different namespaces?
  matt_graphics:line and matt_music:line

If you still needed the container, you could use default
namespacing so the file size would not be different.

Why is containment more useful than subclassing
  line[@class="music"] and line[@class="graphics"]
or specialization
  line[@type="multisegment"] and line[@type="single"].   
This kind of need is much more common than
having uncoordinated development within one
namespace.

The local element declarations exist because the
Schema WG didn't want attributes to have anything
 that elements did not also have.
(This complication is the result of the calls for
"simplification" a few years ago that claimed
that elements should be used instead of attributes.)

Attributes (unless they have a different namespace)
are usually strongly coupled to the element in a way
that elements are not. We can imagine cell of data
outside a table, but a cols attribute divorced from a
table has no independent meaning.  This is reflected
in the syntactic differences between elements and
attributes: an attribute must have an element, but
an element need not have a parent.  

So XML's attribute syntax enforces a distinction in well-
formedness which element syntax cannot: inseperability.

XML Schemas goes even further with this
anti-attribute bias. By not supporting any
subclassing using attributes, it keeps us in
the 1960s world of "gencoding". In the
XML Schema language itself, it means
that instead of being able to say
  <content type="mixed">
we have to have
  <content><mixed>
where specialization is performed by introducing
spurious intermediate elements. 

Cheers
Rick Jelliffe