[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Why Are Schemas Hard?
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: Joe English <email@example.com>, firstname.lastname@example.org
- Date: Mon, 27 Aug 2001 08:25:37 -0500
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
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Joe English [mailto:email@example.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
<!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.)