|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Entities and namespaces in XSchemata
At 23:31 29/05/98 UT, Simon St.Laurent wrote: [...] > >We're not there yet, though. I hadn't even thought about using traditional >general entities in the XSchematas, being too busy dreaming about my other >stuff. They should definitely work for now! Yes. They are as much a part of XML Schemata as are DTDs (I mean the DTD which defines an XSchema itself). We couldn't 'not use them' :-) In principle there is no need to mention them specifically (any more than we mention lt and gt). However it will probably be valuable to add a Note to the XSchema spec. Let us assume (for the moment) that XSchema 1.0 is based just on Elements, Attributes and ContentSpec particles (Seq, Choice, etc.). Assuming the convention that *.dtd is a 'conventional' DTD (e.g. uses <!ENTITY ...> etc.) and *.xsc is an XSchema (i.e. an XML document) and *.xml is a normal XML document instance then we have the following possible documents: greetings.xml <!DOCTYPE greetings SYSTEM "greetings.dtd"> <greetings>Hello world!</greetings> greetings.dtd <!ENTITY greetings.content "#PCDATA"> <!ELEMENT greetings (%greetings.content;)> greetings.xsc <!DOCTYPE xschema SYSTEM xschema.dtd [ <!ENTITY greetings.content "#PCDATA"> ]> <xschema> <ElementType id="greetings"> <Content> <Seq repeatable="no" optional="no">&greetings.content;</Seq> </Content> </ElementType> </xschema> ** Note that greetings.xsc can be converted *algorithmically* to the *normalised* form of greetings.dtd ** This means that the author can effectively maintain greetings.dtd by maintaining greetings.xsc. Indeed she may never even have to learn about parameter entities and do everything through general entities. Of course there is always a danger for beginners of not realising that greetings.xsc, although written in XML document syntax, has a special function - but this is not unique to XML. So the steps that an author would take are: Create greetings.xsc She can use ordinary XML authoring tools for this. (I'll mention below how this is controlled by the 'master' xschema.xsc). This design can include maintainability through entities. Create greetings.xml This process can be *supported* by greetings.xsc (e.g. she would read in greetings.xsc and only be allowed to have #PCDATA as content for a <greetings> element). Transform greetings.xsc automatically into greetings.dtd We can assume this to be trivial and probably a simple add-on to almost all parsers. Validate greetings.xml against greetings.dtd (sic) This will use the conventional current XML validation machinery. At this stage I am definitely not suggesting that we 'redefine' XML to use *.xsc for validation. Note that the parser might have a makefile approach which looked for the latest version of greetings.xsc and - at user option - allowed the parser system to create an update of greetings.dtd. But if this is too hairy, there is no problem in insisting on always using the (normalised) DTD. Note that there will be the additional 'master' documents which we should create communally as a result of this exercise: xschema.dtd This is the DTD governing the validation of (say) greetings.xsc. It will look something like: <!ELEMENT xschema (Admin?, ElementType+)> <!ELEMENT ElementType (Attribute*, ContentSpec)> <!ATTLIST ElementType id ID #REQUIRED> <!-- ... --> It will have an equivalent in xschema.xsc <!DOCTYPE xschema SYSTEM xschema.dtd [ ]> <xschema> <ElementType id="xschema"> <Content> <Seq repeatable="no" optional="no"> <Seq repeatable="no" optional="yes">Admin</Seq> <Seq repeatable="yes" optional="no">ElementType</Seq> </Seq> </Content> </ElementType> <ElementType id="ElementType"> <Attribute id = "id"> <Type>ID</Type> <Default>#REQUIRED</Default> </Attribute> <Content> <Seq repeatable="no" optional="no"> <Seq repeatable="yes" optional="yes">Attribute</Seq> <Seq repeatable="no" optional="no">ContentSpec</Seq> </Seq> </Content> </ElementType> </xschema> <!-- ... --> There will, of course, only be one xschema.dtd and xschema.xsc which will be part of the deliverables from our current work. Note that the (gently recursive) xschema.xsc can be used to support the creation of XSchemas *using any software which supports the creation of XML documents from XSchemas*. In this way there is no need for the creation of a separate suite of software for creating and managing XML DTDs - the same authoring software can be used for document instances and XSchemas. I apologise for any errors in the above (I found a few when I was re-reading). In my opinion the examples I have given define the bounds of the current exercise and I don't think we should go beyond them. Essentially the only decisions are what xschema.dtd should look like (capitalisation, attributes or content models, etc.). And some carefully chosen examples and explanations. I do not see that the xschema above will prevent us from using RDF, adding/subtracting constraints, etc. If we stick to these limited goals I don't see why we shouldn't be finished in the 'mythical XML-DEV month' like SAX. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg 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
|
|||||||||






