XSchema: New draft of John Cowan's proposal

[Toby Speight]

John> John Cowan <URL:mailto:cowan at locke.ccil.org>

=> In article <199806041416.KAA17908 at locke.ccil.org>, John wrote:

John> One problem with XML is that there's no way to say "Attribute B
John> is #REQUIRED iff Attribute A has value 'foo'".

Yes.  This is why I like your use of elements for specifying
defaulting of attributes.  My vote is keep it.

>> instead of having freely mixable content of (ELEMENT|ENTITY|NOTATION)*,
>> it might be better to enforce the grouping of declarations: (NOTATION*,
>> ENTITY*, ELEMENT*).

John> How Pascal-ish!

<g>

John> No, I think it's better to be freely able to associate things
John> that go together in linear order.

I can't remember (nor find easily in the spec) whether notations must
be declared before use.  If so, then I think we should consider
echoing that constraint, to simplify conversion to DTD.  Apart from
that consideration, I have no preference (and it's easy to transform
the document algorithmically, if required).


John> Indeed, I'm thinking that XSchemas should have structure, ...

Sorry, you lost me with this paragraph.  Can you illustrate it with an
example?


>> <!-- 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)>

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

I'm not keen on arbitrary markup, because I'm interested in processing the
documentation with DSSSL to give a pretty-printed human-readable document
to go with the DTD.  It's hard to do that if you don't know what elements
to expect.  And, as I mentioned, we'll want some XSchema-specific elements
to refer to ELEMENT definitions (for example).


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

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

<!ELEMENT ENUM (DOC)>


>> Do entities and notations need documentation?

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

Okay; adding DOC to ENTITY is trickier than the other cases, since its
content-model is #PCDATA - actually, the more I think about it, the
more difficult it seems to treat internal and external entities the
same:

<!ELEMENT EXTERNAL-ENTITY (DOC)>
<!ATTLIST EXTERNAL-ENTITY
	%external;
	notation CDATA #IMPLIED>
<!ELEMENT INTERNAL-ENTITY (DOC)>
<!ATTLIST INTERNAL-ENTITY
	value CDATA #REQUIRED>

Documenting NOTATION is trivial.

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

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

Not really - I think there are other people on this group who are more
qualified than I to do that.  I've only used architectural forms to
create DSSSL documents, and that was very much a trial-and-error
process.  But my motivation stems from the fact that DSSSL documents
must only satisfy the architectural form; this enables individual
(derived) DTDs to use e.g. their own names for the elements (perhaps
in an author's native tongue), but prevents internal subset extensions
from changing the allowed model.

-- 


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)