xml-dev - Fw: XHTML & Schemas

["Oren Ben-Kiki" <oren@capella.co.il>]

Paul Prescod <paul@prescod.net> wrote:
> Let me try to put this argument on a practical footing.
>
> Namespaces are triggers for various things. Stylesheets, validators,
> etc.
>
> For better or worse XHTML has three different grammars. I could probably
> be convinced that this is a bad idea (and on another day might even
> argue vociferously that way). But anyhow, XHTML has three grammars. This
> probably has more to do with politics than technology: "our mandate is
> to blah blah blah".
>
> That means that when we get namespace-aware validators there will be
> three schemas. Schemas are namespace-triggered:
>
>  * not "version attribute" triggered
>  * not DOCTYPE triggered
>
> They are namespace triggered.

<ALARM>WHAT?</ALARM>

> (and for good reason...trying to bring
> attributes into it makes the validation model much more complicated)

I disagree - but I don't quite understand what you mean by "bring attributes
into it" and how it connects to namespaces, so let it pass for a moment...

> It follows that we need three namespaces to attach the three grammars
> to.

<Gulp>It certainly does.</Gulp>

I feel like a fool (that's OK, I'm used to it). I _assumed_ that the matter
of associating a namespace with a DTD/XSchemas was not resolved. There
certainly has been a lot of action going on in this list about it, and
bemoaning of the fact it wasn't cleared anyway. For example, you yourself
have said:

> By this reasoning, it doesn't matter how many different name-space
> prefixes XHTML uses because *none of them* give you a way to know that
> what you are processing is in fact an XHTML document (or XHTML-specific
> element). Rather, the binding between documents and their *governing
> semantic definitions* (e.g., schemas, architectures, etc.) must be
> provided by some other mechanism. In the absence of a generalized
> mechanism for doing this binding, it can only be done in documentation
> of the semantics.

Which, is, of course, a direct contradiction of thee above. Don't feel bad;
Ann has also said:

> (Me:)
> > And/or refer me to some W3C paper which clarifies what the
> > "official view" is?
>
> I don't think you'll find one.
>
> The Namespaces rec was as controversial then as it is now, and opinions
are
> still widely divided.

"When all else fails, read the manual". I went to the XSchema draft and
found the following paragraph
(http://www.w3.org/TR/xmlschema-1/#composition-instances, section 4.1):

    During validation, the standard mechanisms of [XML-Namespaces] are
    interpreted to create associations between instance document prefixes
    and schema definitions. Thus, there is in each valid instance document
    a namespace associated with each schema to which the instance conforms.
    Each namespace qualified element (or eventually entity or notation), its
    attributes and its content, is validated against its declaration in the
    corresponding URI-named schema. In that sense, each schema defines
    and is coextensive with a namespace. The means by which schemas are
    located during processing is discussed below in Access to Schemata.
    Comprehensive rules for validation are discussed in Conformance.

Their example even shows the namespace URI as pointing to the schema - but
another paragraph in the same spec indicates that the processor does not
necessarily uses this URI to download the schema. At any rate...

OK, I'm a fool - I should have gone to the spec before. I have some
mitigating circumstances - one being delivery deadlines, and the other is
the assumption that there wouldn't have been such a fuss over this issue if
it was resolved. Or is it resolved? XSchemas aren't a recommendation yet...
And the consequences of this are so far reaching, and go against so many
deeply held positions expressed in this mailing list - how did this remain
hidden for so long? Is it that people simply ignore XSchemas (as I did :-)?

At any rate, as you've pointed out, the XSchema approach _requires_ the
XHTML use of three namespaces. The fact that I don't like it - and that many
others don't like it - is besides the point. If people want to have a single
namespace for XHTML, they should first go and re-write the above paragraph
in the XSchema draft. Right?

I know better then to ask why XSchemas don't use a DOCTYPE-like directive to
identify the schema. I can see two obvious disadvantages:

- There can't be two different XSchemas referring to the same namespace.
- A document can't obey more then one XSchema (since each element must
belong to a single namespace).

Now, I feel this is too high a price to pay for whatever other advantage the
XSchema WG had in mind. Just as an example, David Megginson has said:

> This is something that SGML got wrong and XML got right -- SGML
> assumed that there was always a *single* DTD that applied to any
> existing document (though that never worked in practice, so we always
> had to invent kludges for non-trivial systems), so that a document
> instance could not exist independently of its schema and vice-versa
> (external DTD subsets are not independent objects in SGML, but simply
> part of the document that includes them).

The quoted section 4.1 of the XSchema draft seems to directly contradict his
view of what's right, so XML did not "get it right". Am I missing something
again?

There's also the small matter of writing XSLT stylesheets, and XPointers in
general. If this namespace-per-each-XSchema idea catches on, someone had
better extend the match patterns to allow saying "{ns1|ns2|ns3}p".
Otherwise, writing match pattern would become hellish.

I don't generally approve of W3C bashing; I think that on the whole they are
doing a good job. But the combination of closed process, lack of rationale
documentation, and the multitude of recommendations is causing a lot of
unnecessary confusion. This effects everyone using these recommendations,
and hence implementations and users. The "second guess the WG" game has to
end. If the W3C insists on a closed process, they should at least commit to
adding rationale documentation to their recommendation - starting from the
very first draft.

Share & Enjoy,

    Oren Ben-Kiki



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)