Lists Home |
Date Index |
- From: "Simon St.Laurent" <SimonStL@classic.msn.com>
- To: "Xml-Dev (E-mail)" <firstname.lastname@example.org>
- Date: Wed, 27 May 98 14:17:24 UT
A revised set of goals for XSD follows, based on public and private comments.
These are still open to change until Friday. If there are changes today, I'll
post them tomorrow, and again Friday morning. Friday's version will hopefully
be the final version. We need to hammer this down and move on to more
specific issues - syntax, implementations, and the rest of the fun.
Per previous usage, XSD (Extensible or XML Structure Definitions) refers to
the standard under construction. SDD (Structure Definition Document) refers to
the schema/XMLDTD/etc. created using that standard. (Better definitions are
on the list of things to come very shortly.)
1. SDDs shall use XML document syntax, using element nesting and attributes to
describe all constraints that may be verified by a processor using XSD.
2. XSD shall define a transformation from SDDs to DTDs.
3. SDDs shall be capable of representing the normalized element and attribute
structures defined in XML 1.0 DTDs.
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, read, and modify.
6. SDDs shall be easy to use in combination with a parser to provide
structural validation of documents.
7. XSD shall include an SDD and an XML 1.0 DTD defining the structure of SDDs.
8. XSD shall suggest mechanisms for applying SDDs to documents.
9. XSD shall include mechanisms for extending the information included in
10. The XSD specification shall be readable,clear, and rigorous, using
terminology and nomenclature as close to the XML 1.0 specification as
11. The XSD specification will comply with and be consistent with W3C
recommendations regarding XML.
12. SDDs shall provide constructs for human- and machine-readable
Note that sequence doesn't matter; I'm putting new entries at the end to avoid
numbering confusion, not to indicate precedence.
Additions: Documentation moved from number 5 to number 12. Machine-readable
documentation may be used by editors or to provide support for literate
programming. This is definitely not a place for style or similar processing
1 - Added "using element nesting and attributes to describe all constraints
that may be verified by a processor using XSD." This comes from Paul Prescod.
I didn't add the XLinks yet; I'd like to leave that open for discussion at
this point. It's an excellent idea, but I'd like to be a little further
before locking ourselves into it.
2 - Replaced the previously loose language with Paul's stricter statement.
5 - Removed 'document' (went to 12) and added 'read'.
7 - Added 'an SDD' to the mix. If we can't define our own structure with an
SDD, it's probably not very useful.
10 - Added rigorous.
3 - Paul Prescod suggested removing it. I like it because it sets a limited
task, the 'normalized' DTDs. I think 'capable of' leaves open the possibility
that SDDs can do more than just this.
5 - Two private respondents have complained that 'easy' is too vague (as in
'easy to create, read, and modify'). To me this means SDD's should be
editable by a human with a reasonable knowledge of XML structures, but I can
see where this may bother people. I like the vagueness, I suppose. Anyone
have a clearer idea?
9 - Should we add some kind of bounds to keep SDDs from redefining document
12 - Alain Deseine proposed a metadata mechanism. I hope we have the kinds of
metadata he needs in this note. I don't want to march on metadata a la RDF
with this module.
Dynamic HTML: A Primer / XML: A Primer / Cookies
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)