Re: Significant W3C Confusion over Namespace Meaning and Policy

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:09:08 UTC