How to have refinement without corruption (Re: Another reason why namespaces URLs should not be schemas)

Mon Jun 21 21:23:30 BST 1999

From: Murray Maloney <murray at muzmo.com>

>We have addressed this problem in XML Schema with the
>import/include distinction. Please take a look.

I have. It does not. They are merely scoping variants for modules.

* Import is a named link to another schema (presumably XML Schema) at
the head of an XML schema document. Declarations from that
schema can be individually accessed.

* Include is an anonymous link to a schema, where the included schema's
declaration take the same namespace as the including schema.

My question must not have been clear. If I use XML Schemas, and
refine HTML, I must also give a new schema URL (masquerading as
a namespace URI). If I give a new namespace URI, then any
XML software which is hardcoded to use namespace URIs will fail.

Surely this prevents the most straightforward implementations
of well-known document types by applications: using the namespace
URI. It seems to me that the current XML Spec is a disaster for
this; I hope I am reading the spec wrong.  If applications have
to download an enormous XML Schema in order to know that
an element is just a refined HTML, then it strikes me as unworkable.

The result will be that everyone will use the prefix to key their
applications
by, and only use the namespace URLs for XML Schemas. It is not
"overloading", it is usurpation.

Rick Jelliffe

P.S. In case anyone is wondering how to have refinement without
corrupting namespaces, one method would be to adopt a
model of schemas which was based on parallel schemas {i.e.,
architectures} where the namespace URI gave the more well-known
parallel schema and therefore was suitable for hard-coded applications.

A simple PI (or attribute) would register the refining schema:
    <?xml-schema namespace="http://..." refinement="http://..." ?>

>At 05:07 AM 6/18/99 +1000, Rick Jelliffe wrote:
>>If I am using XHTML and I decide to refine my
>>document type so that headers must be inside divisions,
>>what do I do (if namespace URLs can be resolved to
>>schemas)?
>>
>>Presumably, I have to derive a new schema based on
>>the old one, with a new URL; then I have to use that new
>>URL as the namespace URL. Then IE 5 and everything
>>that works by using the namespace URL to signify the
>>operation of an element will be broke.
>>
>>This seems to me to be unworkable:  if I make
>>
>><html  xmlns="http://rick.com.xx/my-html.xmlschema">
>>...
>></html>
>>then a rendering engine has to download my corpulent (not to
>>mention grumous) XML schema before it can find out that
>>in fact my element types are HTML.
>>
>>So it seems that overloading the function of the namespace
>>URI to also be a schema URL would have a bad effect on
>>XHTML with data islands etc, or on any DTD derived from
>>DTDs that are built into the processor.
>>
>>It seems that the situation we are reaching is that the
>>namespace prefix is being treated as unique for famous
>>DTDs (e.g. how IE 5 treats html:) and that the
>>URL is being used as a schema name. If people want
>>to do this, that is fine, but it does not correspond to namespaces
>>(in fact, it corresponds more to what I suggested in
>>XML-Bind  -- a simple prefixing system to make
>>automated renaming more manageable and a way to
>>bind names to schemas, except I suggested regular expression
>>matching not just the prefix).
>>
>>Rick Jelliffe
>>

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/ and on CD-ROM/ISBN 981-02-3594-1
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)