Lists Home |
Date Index |
- From: Peter Murray-Rust <email@example.com>
- To: "Simon St.Laurent" <SimonStL@classic.msn.com>,"Xml-Dev (E-mail)" <firstname.lastname@example.org>
- Date: Mon, 25 May 1998 23:11:14
At 18:56 25/05/98 UT, Simon St.Laurent wrote:
>Peter Murray-Rust suggested:
>>I'd also suggest we set goals a la X*L processes, etc.
>The last few messages, particularly the interchange between Peter and Paul
>Prescod, seem to have clarified what we're aiming for, which is considerably
>less than my original proposal. This is good; I think we have an excellent
>chance of achieving these smaller goals.
Excellent. Avoid feature creep at this stage as hard as you can! Remember
we have to implement this. And in my experience it is 10 times harder to
implement something than write it.
>Per the X*L processes, a proposed list of 10 goals follows. I've called
>project XSD (Extensible or XML Structure Definitions) for now. Structure
>Definition Documents (SDDs) are the documents that contain Structure
>Definition information, and XSD is the standard defining the structure of
I suggest we stick with this terminology now. Everyone will have a
different view on acceptable TLAs...
>1. SDDs shall use XML document syntax.
>2. SDDs shall be transformable into an XML 1.0 DTD containing the same
Should either direction be lossless? I suspect that DTD->XML will lose at
least entities, whilst XML->DTD will lose any 'extensions'.
>3. SDDs shall be capable of representing the normalized element and
>structures defined in XML 1.0 DTDs.
Yes - this is the key. Very nicely stated.
>4. SDDs shall be parseable, manageable, and manipulable using the same tools
>used to parse, manage, and manipulate XML documents.
>5. SDDs shall be easy to create and document.
Yes. The documentation is key. Since this is already an extension, this
will be lost on transformation to DTD.
>6. SDDs shall be easy to use in combination with a parser to provide
>structural validation of documents.
This sounds a good idea. It implies separation of the validation and entity
basis of DTDs. At first sight this looks possible.
>7. XSD shall include an XML 1.0 DTD defining the structure of SDDs.
Good point. Essential.
>8. XSD shall suggest mechanisms for applying SDDs to documents.
>9. XSD shall include mechanisms for extending the information included in
>SDDs, and prescribe limits on the behavior of programs using that extended
Not sure about prescribing limits. I think we should simply limit the XSD
spec and ay that *it* doesn't venture beyond certain limits. I would hope
that other extensions would be invisible to XSD and would not result in
loss. (e.g. if someone defines a <FOO> extension to an XSD, the
reconversion to XSD simply involves loss of the FOO info and no other
>10. The XSD specification shall be readable and clear.
Excellent. I would add (somewhere) that the XSD spec should use terms and
nomenclature as close to the XML 1.0 spec as possible. Element names and
attributes should use the precise names including case if possible.
>This is a _start_. Changes to language, meaning, order, terminology, etc.
>all welcome, as are additions. Ten is traditional, but not required.
There are several other specs with more than 10 (ca. 13 is the max).
Excellent. Somewhere in here we need that XSD documents (i.e. the
'schemas') should be human-readable and machine documentable. They should
have simple 'hooks' so that components (e.g. elements) can be linked to
machine-help (e.g. Java Swing toolTips)
I think this document prescribes and proscribes sufficiently for us to get
started, but those who expect more from this effort should clamour for a
chance to 'vote' upon it. Personally I think we've got it about right.
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)