Lists Home |
Date Index |
- From: Toby Speight <email@example.com>
- To: "XML developers' list" <firstname.lastname@example.org>
- Date: 04 Jun 1998 15:16:47 +0100
John> John Cowan <URL:mailto:email@example.com>
=> In article <199806041416.KAA17908@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!
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
>> <!-- 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
<!ELEMENT EXTERNAL-ENTITY (DOC)>
notation CDATA #IMPLIED>
<!ELEMENT INTERNAL-ENTITY (DOC)>
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:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)