Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSchema: New draft of John Cowan's proposal
 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@c... e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
