RE: Namespaces, schemas, Simon's filters.

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

Rick,

> -----Original Message-----
> From: Rick Jelliffe [mailto:ricko@allette.com.au]
> Sent: Tuesday, August 21, 2001 8:35 PM
> To: Xml-Dev
> Subject: Re: Namespaces, schemas, Simon's filters.
> 
> 
>  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
> 

Beats the h*ll out of me.  I would.  In fact I demonstrated how to do this
in an earlier post this week (I'm offline right now, so I can't point to it
on the server) and showed how it would be semantically, if not
syntactically, equivalent.

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

Quite right.  And I argued along those lines - each type creates its own
namespace which local elements and attributes occupy.  However we (Schema
WG) wouldn't sanction that notion.  I continued arguing for the current
default as it doesn't prevent moving to a better solution in the future
(unlike explicitly putting them in the namespace of the schema, which ties
them to a particular solution forever).  If one does that, of course, then
xsi:type really indicates the namespace of the element's content, so it's a
kind of xmlns attribute.  And then complex types become the foundations for
a module system.

> Why is containment more useful than subclassing
>   line[@class="music"] and line[@class="graphics"]
> or specialization
>   line[@type="multisegment"] and line[@type="single"].   

I do not understand your distinction between subclassing and specialization.
Could you please elaborate?  However "specialization" seems to be what you
get with xsi:type, so it's handled.  

> This kind of need is much more common than
> having uncoordinated development within one
> namespace.
> 

But if we consider each type as creating a separate namespace, then it
isn't.  I created local elementTypes in SOX (the progenitor of XSDL's local
elements) to handle 2 related use cases.  

The first was to handle the many elements I saw in DTDs at the time which
were clearly intended to occur only in the content model of some particular
other element - and nowhere else.  In two words - "containment" and
"inseperability" (to skip ahead in your argument) - and they were quite
important.  This was being handled by the creation of ridiculously long
names - the line inside graphic was named graphic.line to distinguish it
from text.line, so the element became <graphic><graphic.line/></graphic>.
For some reason people found this artificial and annoying, and
<graphic><line class="graphic"/></graphic> doesn't strike me as likely to
garner more support.  Declaring an element in the only place it was to be
used was simply better syntax.

The second use case was to distinguish different uses of the same type
within the same element.  My canonical case was the purchaseOrder with two
addresses, one named billTo and one named shipTo.  Of course, one could
instead have a sequence with two addresses and just know that the first is
the billTo and the second is the shipTo, and that's fine if you're a
compiler.  People prefer mnemonics.  And again, since this association was
idiosyncratic to the context (purchaseOrder) there wasn't any need to
pollute the rest of the schema with this entirely local association.

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

Sorry Rick, but this is completely offbase.  I created local elements for
SOX for the reasons I've indicated.  I've never even thought about
attribute/element distinction for this and don't remember this ever being
discussed - and I've been in the WG since day one.

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

I assume you mean preschema 1.0.  In any case the word is "doesn't" not
"cannot"

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

As far as I can tell, xsi:type is subclassing using attributes.  And I
totally agree with you here - earlier versions of XSDL used an attribute for
mixed, and when the syntax changed, I actually argued for xsi:type="mixed",
but actually exploiting the features we'd created was just too radical.

Matthew