Lists Home |
Date Index |
- From: email@example.com (Ron Bourret)
- To: firstname.lastname@example.org
- Date: Thu, 25 Jun 1998 11:54:23 +0200
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
> > 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;
> <!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:
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:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)