W3C home > Mailing lists > Public > www-tag@w3.org > February 2005

Re: Significant W3C Confusion over Namespace Meaning and Policy

From: Patrick Stickler <patrick.stickler@Nokia.com>
Date: Wed, 23 Feb 2005 10:33:59 +0200
Message-Id: <7ddd9a2b557f4839fdd2b1d43c26452f@nokia.com>
Cc: www-tag@w3.org, "ext Karl Dubost" <karl@w3.org>
To: Patrick Stickler <patrick.stickler@Nokia.com>

Of course, this proposal runs into the brick wall of
issue httpRange-14, since the value of xml:model
would be (ideally) an http: URI identifying a model
(e.g. a schema) and not a document, and for some
(not me, obviously) to use an http: URI to identify
a non-document resource would be considered wrong.

(Oh, that we could put httpRange-14 behind us and move on...)


On Feb 23, 2005, at 10:07, Patrick Stickler wrote:

> On Feb 22, 2005, at 23:19, ext Karl Dubost wrote:
>> Le 18 févr. 2005, à 10:22, Norman Walsh a écrit :
>>> I'm hoping that the combination of namespace name and version will be
>>> sufficient. Making the version a URI might be a good idea though,
>>> since DocBook can be extended by others. (Without changing the
>>> namespace!? Yep. Such has it always been with DocBook.)
>> There are many languages where we can't give the version information.
>> What's happening with composite documents with multiple namespace? 
>> How do we go back to the version information?
>> For example how do I know if I use xml:id version 1.0 or xml:id 
>> version 2.0 (if there will be one in the future? Or even funnier if 
>> xml:id becomes part of a future XML 2.0
> I see (at least) three distinct cases here:
> 1. There is an explicit document model (schema) which provides for
>    the interpretation of all terms in any valid instance of that
>    model (no ANY element content, etc>), such that one can use
>    <!DOCTYPE to refer to the schema document relating to the particular
>    version of the particular schema (thus, for this case, no problem).
> 2. There is an explicit document model which employs elements with ANY
>    content and there are instances which specify via <!DOCTYPE which
>    version of which schema applies to the root document, yet the
>    document also includes terms from other document models in the 
> content
>    of elements allowing ANY content, such that it is  not clear from 
> the
>    namespace names of those "foreign" terms which version
>    of which document model (schema) should be used to interpret
>    them, since the schema for the root document model does not say.
> 3. There are well-formed XML instances which specify no <!DOCTYPE and
>    which employ terms from various document models, and it is unclear
>    from the namespaces of the terms, including the root element, which
>    versions of which document models (schemas) might apply.
> The problem of the last two cases is the same: how to identify which 
> version
> of which model(s) to apply when interpreting the document instance.
> (there is a secondary problem dealing with potential conflicts of
> interpretation between models and non-licensed insertion of "island"
> fragments in places not explicitly licensed by a given enclosing model,
> but let's leave that for now...)
> The solution to the above noted problem needs to achieve one key
> goal: map from a given term to a particular version of a particular
> model (schema/ontology/whatever). Note that the mapping is from
> the term to the model -- not the namespace to the model!
> The mapping should also be defined as locally as possible in the
> document instance, since, with island data, different versions of
> the same model might be (wished to be) used in the same encompassing
> document without confusion (this is especially important where
> content is being syndicated from multiple sources and combined
> into a single document for presentation and the agent cannot
> be overly particular about the versions and models used to
> express the data components).
> Thus, it seems to me that what is needed is something like an
> attribute xml:model which can be inserted in the root element of
> island fragments, and which overrides/hides any xml:model declaration
> of the enclosing scope. This xml:model attribute would take a URI
> as its value, and that URI is constrained by the semantics of this
> attribute to identify a model of some sort (schema/ontology/whatever).
> The model URI can then be dereferenced to obtain representations of
> that model (e.g. RDDL or RDF etc.) which provides information about
> which resources should be used to process information expressed
> per that *specific* version of that *specific* model (i.e. various
> schemas, ontologies, style sheets, etc.).
> The <!DOCTYPE declaration could also be extended to include a model=
> attribute; or alternatively xml:model could simply be used on the root 
> element
> in conjunction with the <!DOCTYPE declaration (which may be a more
> backwards compatible way to introduce an attribute such as xml:model).
> --
> What such an approach offers is
> (a) a means to be explicit about which version of which model
>     should be used to interpret the entire instance or any
>     given "island" sub-branch of the instance
> (b) a means to create composite documents employing components
>     corresponding to any version of any model without ambiguity
>     or conflict of interpretation
> (c) a means to publish representations of the particular versions
>     of the particular models via the URIs identifying them
> (d) no need whatsoever to look at namespace names and deal with the
>     ambiguous mapping from namespace names to particular versions
>     of particular models employing terms grounded in those namespaces
> Legacy tools should simply ignore the xml:model declarations.
> New tools will utilize them to properly interpret components
> of composite documents by being told the specific version of
> the specific model associated with that fragment, and to be
> made explicitly aware of the specific version of the specific
> model associated with the root document element.
> --
> And if folks find it useful to publish namespace documents,
> then those namespace documents can refer to the particular
> versions of the particular models utlizing terms from those
> namespaces -- using the URIs of those model versions, thus
> nicely tying together the body of information available for
> understanding and utilizing web content.
> Thus, humans pasting namespace names into their browser
> address bar won't get a nasty shameful 404 response, yet
> tools will be able to focus on models and data expressed
> per specific versions of specific models, and not be
> concerned in the least with lower level syntactic issues
> such as namespace names.
> Eh?
> Patrick
Received on Wednesday, 23 February 2005 08:34:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:45 UTC