Re: Reject W3C XML Schema: structures

Dean Roddey wrote:
> My personal believe, as a parser writer, is that the Schema spec, as is,
is
> far too complex.
....

> Just my opinion of course...
>
>

Which really should be thoughtfully considered by the XML Schema WG.

I definitely agree with the layered approach and have half-heartedly
mentioned it previously.  A lot of things in XML Schema are convieniences to
the schema author that should be processed out before using for validation.
Each validation should not be required to fetch all the import and included
schemas and resolve all the inheritance and equivClass issues.

I'd break things in XML Schema (structures) into three levels:

A) Those things that are poorly defined or overly complicated with respect
to the value they add that should be eliminated.

1. Inheritance by restriction for content models.  There is not a simple way
to identify what element in the content that you are tweaking and the same
objectives can be acheived more intuitively with groups
2. Reinterpreting content models.  I've suggested unifying the equivClass
behavior with the existing group mechanism.
3. The "all" content model.  They fact that it can only be used in the
top-most level restricts the motivation for its existance
4. xsi:type, it just scares me and I'm not sure of what it is good for.
5. I'm sure there is more

B) Those things that are a convience to the schema author but should be
preprocessed out before use in validation (maybe by a standard XSLT
transform)

1) Import, include
2) equivClass
3) Inheritance by extension
4) Possibly attribute groups and groups

C) The essential core needed for validation

1) Datatype definitions
2) Element definitions

D) The additional things needed in Schema so that it can effectively
self-validate minimizing the custom code needed to check the schema.

1) The ability to have different "type"'s based on the presence or absence
of the "name" or "ref" attribute

Hopefully, all the parser writers would have to support is C+D.  Hopefully,
all the features in B could be defined so XSLT could transform them to set
C+D (may take multiple passes).  Ideally, a schema publisher would have his
source and "compiled" version of schemas and the "compiled" version would be
the one used in validation and referenced in xsi:schemaLocation.  If a
parser detected a B feature, it could be nice and invoke XSLT processing,
however that would not be required.


--------------------

For anyone on the thread on comp.text.xml who were talking about schema
documentation, check my help file at
http://www.software.aeat.com/xml/resources.htm or Roger Costello's tutorial
http://www.xfront.com/xml-schema.html .

I have not had a chance to update my schema documentation tool (used to
produce my help file) to the latest draft in time to author the help file in
Dec XML Schema (it is authored in a variant of May XML Schema).  However, if
a rag-tag team wants to develop HTMLHelp, JavaHelp and HTML pages from an
annotated schema for schema starting with the next draft, I'd be willing to
help with the technology.

Received on Tuesday, 18 January 2000 23:02:00 UTC