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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: XSchema: New draft of John Cowan's proposal

[ Lists Home | Date Index | Thread Index ]
  • From: John Cowan <cowan@locke.ccil.org>
  • To: xml-dev@ic.ac.uk
  • Date: Thu, 4 Jun 1998 10:16:50 -0400 (EDT)

Toby Speight wrote:

> I'm not sure if the name "VALUE" for the default value of an attribute
> is the clearest possible:
> For somebody reading an actual Xschema, it might be assumed that VALUE
> represented a fixed, rather than default, value - particularly if
> FIXED never occurs in that particular Xschema.  Would FIXEDVALUE and
> DEFAULTVALUE be better names for FIXED and VALUE?

Doubtless they would.  The name VALUE was an attempt to compromised
between "default value" and "enum name", which latter is now ENUM.
So VALUE can be changed.  I'm also wondering if this mightn't now be
a case for an attribute instead of a bunch of empty elements.
One problem with XML is that there's no way to say "Attribute B
is #REQUIRED iff Attribute A has value 'foo'".

> Another issue which different people will have different opinions on
> is the content of the DOCTYPE element - instead of having freely
> mixable content of (ELEMENT|ENTITY|NOTATION)*, it might be better to
> enforce the grouping of declarations: (NOTATION*, ENTITY*, ELEMENT*).

How Pascal-ish!  No, I think it's better to be freely able to associate
things that go together in linear order.

Indeed, I'm thinking that XSchemas should have structure, allowing
DOCTYPE to be an element.  I had discussed this yesterday wrt embedding
external XSchemas, but it would also be useful for indicating
sub-schemas, rather than just a rag-bag of declarations.   In the meta-XSchema,
e.g., there would probably be separate subschemas for ELEMENT and
friends, ATT and friends, ENTITY, and NOTATION.

> <!-- use #PCDATA for this now; we can loosen the content model as the
>      spec evolves (in particular, we will want to link to IDs
>      elsewhere in the XSchema -->

I still think that ANY is the right thing, so that arbitrary markup
(XHTML or XTEI or whatever) can be used here.


These look good.

> Do individual ENUM values need documenting?  Or is it sufficient to
> have the DOC in ATT describe them?

I would say yes, they should allow documentation, for modularity.

> Do entities and notations need documentation?

Surely!  One purpose of documentation is to describe *purpose*, and
understanding a notation will often require knowing its purpose:
not everybody knows what "PERL5.x" means, still less "RipScrip2.0".

> A final comment, on conformance: should valid documents having a DTD which
> uses the XSchema DTD as a base architecture be considered conformant?  Or
> should we insist that only the results of architectural forms processing
> can qualify?  (Using architectural forms means that an internal subset may
> be used if it is compatible with the base architecture.

I can't comment, as I don't understand architectural forms.  Can you
give a simple concrete example?

> Incidentally, I
> think an internal subset should be allowed in conforming XSchema documents,
> if it contains only general entity definitions (and notations?); as it is,
> entities must be expanded.)

Hmm.  Good point.

John Cowan					cowan@ccil.org
		e'osai ko sarji la lojban.

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