[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Why Are Schemas Hard?

  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • To: Joe English <jenglish@f...>, xml-dev@l...
  • Date: Mon, 27 Aug 2001 08:25:37 -0500

RE: Why Are Schemas Hard?
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

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

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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.