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: Toby Speight <tms@ansa.co.uk>
  • To: "XML developers' list" <xml-dev@ic.ac.uk>
  • Date: 04 Jun 1998 15:16:47 +0100

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

=> 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*,

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

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.


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

	notation CDATA #IMPLIED>

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