Lists Home |
Date Index |
- From: Philip Nye <email@example.com>
- To: XML Developers' List <firstname.lastname@example.org>
- Date: Thu, 16 Sep 1999 11:00:17 +0100
Tim Berners-Lee wrote:
> In this case, the only information which a Transitional-capable receiver
> of information needs to be able to process a Strict document is
> "Strict is-a-subset-of Transition"
> This gem could be <snip> - picked up from the document itself
> The latter case is useful where you have an in-house subset of
> a language but you want generic browsers to know that the
> language can be processed as xHTML.
and then in another post:
> I feel that language subsets are completely well defined, by the change
> of namsespace preserving validity.
> I think that you can in fact crystalize the concept of "general language"
> by specifying a set of languages which are all subsets of a given
> language L. So for example if you define xHTML-all as a
> language whose document content model accepts any strict or
> transitional or frameset document, then you can use that
> namespace for refering any xHTML document. You now have a clean
> definition of validity, and well-defined compatability rules.
I get the strong sense that your view is that subsetting is "good" and
useful (my own feelings exactly). What I don't understand is why this
obvious point is not reflected in the namespace spec.
A namespace URI is the ONLY place a processor can reliably determine
what language a document is using. What magic tells that processor that
the unknown URI is actually a subset of a known one?
Currently adding one single element type to language L creates a
completely new and unrelated language. There is no reliable way for a
processor to know that L is a subset of L+ other than having that
knowlege hard coded into the application.
Now substitute XHTML-strict, XHTML-transitional for L and L+ in the
above statement then add XHTML-all and move forward a few versions and
you have a mess. This is not really the fault of the XHTML group at all
- it is an early manifestation of the weakness in the current namespace
and schema spec. However, it is a high profile manifestation which will
directly affect many people and the solution or workaround is not at all
This seems to be at the root of much of the controversy on this issue.
Namespaces have no structure whatever. Schemata have lots of structure
but no guaranteed recognition and access mechanism. Proposals for
hierarchichal namespaces don't seem to meet much interest. Processing
instructions are deprecated. So are external entity references. So how
should we do it?
Engineering Arts UK
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/ and on CD-ROM/ISBN 981-02-3594-1
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)