XSchema: New draft of John Cowan's proposal

[John Cowan]

Toby Speight wrote:

> I'm not sure if the name "VALUE" for the default value of an attribute
> is the clearest possible:
> 
> John> <!ELEMENT ATT ((TYPE|ENUMTYPE)?, (REQUIRED|IMPLIED|FIXED|VALUE))>
> 
> 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 -->
> <!ELEMENT DOC (#PCDATA)>

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

> <!ELEMENT DOCTYPE (DOC?, (ELEMENT|ENTITY|NOTATION)*)>
> <!ELEMENT ELEMENT (DOC?, (EMPTY|ANY|MIXED|REF|CHOICE|SEQ), (ATT)*)>
> <!ELEMENT ATT (DOC?, (TYPE|ENUMTYPE)?, (REQUIRED|IMPLIED|FIXED|VALUE))>

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 at ccil.org
		e'osai ko sarji la lojban.

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)