XSchema Spec Section 2.4, Draft 2

[Ron Bourret]

Chris Maden wrote:

> This seems unnecessarily verbose in the extreme.  What's wrong with
> 
> <!ELEMENT XSC:AttDef (XSC:Doc?)>
> <!ATTLIST XSC:AttDef
>           Name        NMTOKEN       #REQUIRED
>           Type        (CData |
>                        ID |
>                        IDRef |
>                        IDRefs |
>                        Enitity |
>                        NmToken |
>                        NmTokens |
>                        Notation |
>                        Enumeration) "CData"
>           Required    (Yes |
>                        No)          "No"
>           Fixed       (Yes |
>                        No)          "No"
>           Enumeration NMTOKENS      #IMPLIED
>           Default     CDATA         #IMPLIED>

This roughly matches John Cowan's original proposal.  Neither he nor I had very 
strong feelings way as to whether to use it or the current proposal.

The advantage of this is conciseness -- not only is the DTD easier to read, the 
resulting XSchema document is also easier to read.  The disadvantage is that it 
allows people who write XSchema documents to make mistakes that a validating 
parser would catch if the current method is used, such as declaring that the 
type is an enumeration and then omitting the enumeration.  (The same logic was 
used while developing the notation declaration syntax.)

However, as time has progressed, it has become obvious that XSchema applications 
will need to validate more of the XSchema itself than was originally hoped.  In 
light of this, it might be worth considering syntaxes such as this that rely on 
(a) a more sophisticated XSchema checker and (b) people reading the 
documentation.  Note that an XSchema checker, which could be written as a Java 
class that other XSchema applications could extend, checks the XSchema itself, 
as opposed to using the schema information defined in XSchema to validate/verify 
another XML document.

One other problem with the above syntax is the use of NMTOKENS for the 
enumeration.  An earlier objection on this list pointed out that most parsers 
today return a string of Nmtoken's, rather than an array, which forces the 
application to parse the string themselves.

> Here's where it gets interesting: Does XSchema have to limit itself to
> the capabilities of DTDs?  If so, why bother?  Think about this:
> 
> <XSC:AttDef Name="one-of-these" Type="IDRef" Required="Yes"
> Enumeration="index biblio gloss"/>
> 
> You can't do that with DTDs.  The value for one-of-these must be
> specified, and it must be a legitimate IDREF, but it is constrained to
> one of the specific IDs listed.

I like this :)

I think XSchema 1.0 ought to limit itself to the capabilities of DTDs, only so 
that we could get something out the door.  However, I have always felt that in 
the long run, it should be a building block for additional constraints, such as 
the one Chris mentions here.  If such extensions won't be possible, we've got 
problems.

> > In XSchema 1.0, an attribute declaration (XSC:AttDef element) must
> > be nested within the element declaration (XSC:ElementDecl element)
> > for the element to which the attribute belongs.
> 
> This gives less functionality than XML DTDs, since you can have
> multiple ATTLISTs for one element type.  XSchema should provide that;
> maybe
> 
> <!ATTLIST XSC:AttDef
>           ElementType NMTOKEN #IMPLIED>
> 
> If the AttDef specifies an ElementType, it applies to the named
> element type.  If not, and it is contained in an ElementDecl, then it
> applies to that element type; otherwise it is an error.

Chris has a good point here -- the current XSchema proposal doesn't allow you to 
import an XSchema and add your own attributes, which DTDs do allow.  I think 
this functionality is what John Cowan intended with his AttGroup proposal.  A 
more interesting way of doing this would be:

<!ATTLIST XSC:AttDef
          Elements NMTOKENS #IMPLIED>

This would allow you to easily specify attributes that apply to a number of 
elements.  We could also state that, when the Elements attribute is omitted and 
the AttDef is outside an element definition, it applies to all elements.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)