Entities and namespaces in XSchemata

[Peter Murray-Rust]

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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)