Lists Home |
Date Index |
>> Nicolas Lehuen wrote:
>> I agree with most of what you write. Note that schemas are not
>> wholeheartedly on one side or another. Even though each
>> may only work with one namespace you can of course make a
>schema for a
>> multi-namespace "document type" (or "MIME type") by using inclusions.
>Right, and to be totally clear it is not tenable to equate
Well, I tried to play a "what-if" game about this in :
It turns out that equating namespace and types (scenario 2) seems to be
possible, and as powerful as the opposite (scenario 1).
The problem is that in either case, we have to actively change the current
situation. In both scenario, we have to change some concepts and
technologies to consistently match the choice we would have made.
We cannot just say "namespaces != document types, once for all" and not do
anything about certain technologies which assume the opposite (like XML
Schema). For the moment, the XML world is not consistent about the meaning
or absence of meaning of namespaces, which could be a major source of
headaches in the near future. In think we'll have to chose one scenario or
the other, publish it and proactively fix what needs to be fixed. The big
question are :
- which scenario is the best one for the future ? I.e. are the two scenarii
equally powerful, or is there a scenario that would be more interesting with
regards to technology ?
- which scenario is the less expensive ? In either case, we'll need to break
things and build new ones. What scenario has the easiest migration path ?
But maybe that's more the responsibility of W3C to decide about that...
>1. XML documents that don't use namespaces certainly have a
>2. the document type is a property of the document i.e. the instance,
>whereas the namespace is a property of the element
>3. XHTML is the perfect example (and note that RDDL is an
>where the "html" element must be qualified by the
>http://www.w3.org/1999/xhtml namespace but, particularly when
>XHTML modularized schemas, one would not expect to find a, for example,
>private modularized XHTML schema located in the description of
>I.e. there are an infinite number of possible schemas which
>conform to XHTML
>modularization and whose instance documents have the root "xhtml:html".
Yup, but if we went for the scenario 2 (as I described in my 'what-if'
mail), we would never try to define a schema for a complete XHTML+Modules
instance document, because the requirement for namespace insulation in
schemas would not allow us to do so.
It doesn't mean XHTML cannot be done in scenario 2, though. All schemas
would be modular, with delegation points to allow the inclusion of foreign
namespaces in instance document. That is to say that to validate an XHTML
document with modules, you would first begin with an XHTML schema (since the
root element is in the XHTML namespace), and when encoutering a different
namespace, delegate the validation to an appropriate schema bound to the new
>Perhaps the main issue is that if we are finally jettisoning
>DTDs, we ought
>to have a replacement for the <!DOCTYPE> declaration (modulo
>subset - groan). It would be good if the schema pointed to by this
>declaration where not hardwired to a single schema declaration
That's why I suggest that the replacement for the DOCTYPE declaration points
to a resource directory rather than a resource of a particular type (that
is, if we follow the scenario 1). This will not only allow to bind a
document type to many schema languages, but also to stylesheets,
Java/C#/whatever code, etc.
>This issue is IMHO orthogonal to namespaces.
So do you think we should follow the scenario 1 ?
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>To subscribe or unsubscribe from this list use the subscription