XSD: Extensions

[Peter Murray-Rust]

At 01:07 28/05/98 -0400, Paul Prescod wrote:
[...]
>
>I've been thinking about this issue at length.

And the time has been very well spent. This is an excellent document.
>
>There are three kinds of extensions I can imagine:
>
> 1. Metadata extensions. These are harmless and quite powerful and useful.

Agreed. (perhaps 'mostly harmless' :-) See below.

>
> 2. Constraint addition extensions. A constraint extension is an extension

I imagine that data typing (Integer, Float, etc.) falls into this category.
>
> 3. Constraint relaxing extensions. This form does the opposite. For
>instance we might define NUMBER to take only numerals, as XML does.

err... I don't think XML has a builtin 'NUMBER'. Did you mean SGML?


>I'm starting to remember why I was so leery of schema extensibility in the
>first place. Essentially, we are running into the verification version of
>the "HTML Optimized for Netscape" problem. The solution to the HTML

Yes. XML is now tackling the problems of semantic interoperability. We
always knew this was coming. HTML can, of course, break on syntactic
non-interoperability as well :-) - XML has not removed the problem but it
has helped identify it better.

>problem was XML+XSL -- extensibility and a way to define the results of
>extensions. The equivalent in SDD would have to be some way to "plug in"
>schema language extensions in a portable way (ECMAScript, Java?). This is
>way outside of our mandate. Thus, I think that these forms of extensions
>are also outside of our mandate.

Yup!!

>
>I would suggest that the only type of extension that should be explicitly
>allowed in version 1.0 is metadata. The verification language's semantics
>should not themselves be extensible. E.g. every XSchema 1.0 verifier in
>the world should agree on whether a document conforms to a particular
>XSchema or not.

Yes.

We should stick absolutely to metadata.  I see this as breaking down as
follows:
	- per-document metadata. What does this XSD do? What other tools are
associated with it? who regulates its use? Where's its home page, etc. What
other namespaces (XSchemas) does this document depend on (e.g. a DTD for
pharmacopeias might require CML).
	- per-component metadata. What does <FOO> mean? does CLASS have consistent
semantics on every element?
	- inter-element relationships. This is tricky, and I think falls outside
our remit.

I see four ways of adding metadata:

	- through embedded <HELP> information. I see no reason not to use HTML for
this, so already we have a requirement for metadata :-). I have already
posted an example - I suspect we only have to agree on syntax.

	- through stylesheets. Although a stylesheet can be imposed at many
stages, it may be valuable for the XSD to carry the 'definitive' stylesheet
info (or a link to it).  

	- through links to glossaries (my own indulgence :-). An element <FOO> can
be linked to a definitive (XML) glossary entry describing its use. This
glossary can have its own semantics. Thus a glossary for <UNITS> could have
links to conversion factors (e.g. lb2kg). An obvious example is that if we
create an element <AttName> it can be linked to a glossary from rec.xml.
[BTW I hope to publish the VHG DTD later today.]

	- through mappings to behavior, especially Java classes. At present I use
something like:
<NAMESPACE id="CML">
	<ELEMENT id="MOL">
		<JAVA>uk.co.venus.cml.MOLNode</JAVA>
	</ELEMENT>
</NAMESPACE>

this says that <MOL> can be processed with the Java class above.

Only the last of these has non-human dangers. I would defend it by saying
that it is a clear statement of the unique resource required to
process/display/render/transform/ this element. If someone wishes to
override it locally, fine. But - unlike the XSchema extensions that Paul
rightly deprecates - it can be made globally unique. And in many cases code
will be the only way of defining the semantics - 'this is what a FOO does'.

[...]
>We can do the same in XSchema. The XLink verifier's rules can be opaque
>"metadata" as far as an XSchema verifier is concerned, but another
>process, for instance an XLink verifier can still do its job based on this
>metadata. What does this subtle difference mean in practice? It means that
>it would be illegal for MozXSchema to say:

I am glad to see that Paul has brought up XLink - I am sure it will be part
of XSD in later versions, but I suspect we shouldn't build it into our
first go.

BTW - if you think that the concept of 'namespace' is just under the
surface of this posting, you're right. Many XSDs will very likely be
directly mapped onto namespaces or alternatively give metadata about what
namespaces are used in a document. On re-reading the namespace proposal
yesterday I realise how closely linked to syntactic processing it is
('namespaces may be part of future versions of XML'). I suspect that the
next generation of parsers will deal directly with some aspects of
namespaces (I'll post separately to XML-DEV on that). So let me also propose:

	XSDs shall support namespaces.

I am not expecting anything hairy from this - probably a metadata catalog
of the namespaces that are directly related to an XSD. 

	P.

BTW I have probably been imprecise in my use of XSD.
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)