RE: Why Are Schemas Hard?

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Yes, as others are starting to realize.  Newcomb 
once said that the GI was just "the big attribute" 
and folks seem to miss what he was saying.  I 
think there is a disconnect here and it shows 
up more explicitly the further into schemas 
one digs.  For example, lists and unions.  
Way beyond DTD at thtat point.

Over the last year, several times people have 
equated the generic identifier to be a type name 
or class name.  SGML says "element type definition" 
but that is a content model name, really.  Schemas 
does really mean "type" but the semantics of that 
are vague.  Some (including me) say that trying 
to make XML an object-oriented programming language 
is a bridge too far.  On the other hand, one can 
make an application language do almost anything 
(nodes is nodes).  I think XML Schemas are too 
hard because we aren't really sure what they 
are supposed to do and it really has become 
an off-camera scene where the audience is 
filling in what the author could only imply 
given the censors don't allow some things to 
be said explicitly.  For me they are easy 
because like yourself, most of what I want 
to represent can be done in DTDs.  Still, 
I find myself creating restricted simple 
types for reuse to pick up the extra power 
of regexes and that is a step beyond DTDs.

It seems to me that to accept and apply 
schemas, PSVI is inevitable but until we 
accept that, Schema can't cross the right 
bridge.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Joe English [mailto:jenglish@flightlab.com]

I just wrote:

> When I figured out that the sample XSD fragment
>
> | <complexType name="myNewNameType">
> |	[ ... ]
> | </complexType>
> | <element name="employee" type="dc:myNewNameType" />
>
> means, basically,
>
>     <!ELEMENT employee 	(name, location) >
>     [...]


Of course the XSD version and the DTD version don't
*really* mean the same thing; the XSD version defines
several things that the DTD can't even express
(a new type "myNewNameType" which can be subclassed and
reused, locally-scoped type bindings for the generic
identifiers 'name' and 'location', etc.)

It's just that most of the time I don't need any of the
extra things that XSD can express; usually I just need
to say

     <!ELEMENT employee (name, location) >

XSD makes explicit a lot of what's implicit in the DTD syntax.
On the one hand, this lets you override, name, and reuse
these entities; on the other hand, it makes you spell them
out.  (The shorthand versions can save some typing, but the concepts
are still there, implicitly explicit.)