OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: XSchema Spec Section 2.4, Draft 2

[ Lists Home | Date Index | Thread Index ]
  • From: Chris Maden <crism@oreilly.com>
  • To: xml-dev@ic.ac.uk
  • Date: Wed, 24 Jun 1998 16:59:24 -0400 (EDT)

[Simon St.Laurent]

> <!ELEMENT XSC:AttDef (Doc?, (CData | ID | IDRef | IDRefs | Entity |
> Entities | NmToken | NmTokens | NotationType |
> EnumerationType),(Required | Implied | Fixed | AttValue))>
> <!-- Name is the name of the attribute -->

[First of all, all those child elements need namespace qualifiers.]

This seems unnecessarily verbose in the extreme.  What's wrong with

<!ELEMENT XSC:AttDef (XSC:Doc?)>
          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>

The name is the name of the attribute.

The type is the type of the attribute; if the type is Notation or
Enumeration, then the enumeration attribute is required.

The required attribute takes "yes" or "no"; "yes" is the same as
#REQUIRED; "no" is the same as #IMPLIED.

For the fixed attribute, "yes" is the same as #FIXED, and "no" is the
same as its absence.

The enumeration attribute takes a list of tokens (since only tokens
can be given in an enumerated list).

The default value is just that; it must comply with whatever type was

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.

Another example that someone in this group (one of the Peters?) raised
is default ID names.  This is illegal in XML 1.0, but for my <index>
element, nine times out of ten, the ID is "index".

<XSC:ElementDecl name="index">
  <!-- whatever content model -->
  <XSC:AttDef Name="id" Type="ID" Default="index"/>

> <!-- XSC:CData through XSC:EnumerationValue identify attribute types -->

Any time you have a huge slew of EMPTY elements, think that maybe they
should be attributes.

> 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;

          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.

And BTW, I still don't like this capitalization method.  I'm all for
<xsc:attdef>; I do all my coding by hand (and so will everyone else,
until an XSchema editor is written; don't hold your breath).

<!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
"<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487
<USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS