Re: Significant W3C Confusion over Namespace Meaning and Policy

[I'm responding offlist simply to reduce traffic to the TAG 
specifically]


On Feb 18, 2005, at 12:18, ext Robin Berjon wrote:

> Patrick Stickler wrote:
>> Namespace documents are not backwards compatible with existing
>> use of namespace names -- since one cannot impose a reinterpretation
>> of what those namespace name URIs identify such that they would
>> identify namespace documents.
>
> And they don't. It was always an option that one could perhaps 
> retrieve a representation from a namespace URI and putting something 
> there doesn't change the nature of namespace URIs in any way.
>

You missed my point. E.g.

<ex:foo xmlns:ex="mailto:some.person@some.org">...</ex:foo>

This is a perfectly valid use of XML namespaces, yet no automated
software agent can presume that <mailto:some.person@some.org> can
resolve to a namespace document.

Here's a more realistic example:

<ex:foo xmlns:ex="http://www.some.org/">...</ex:foo>

where it is elsewhere understood and even formally asserted that

<http://www.some.org> rdf:type xyz:Organization .

(where xyz:Organization is the class of, well, organizations)

Thus neither URI used as namespace names above identify
namespace documents, and yet the function perfectly well
as namespace names, exactly as intended.


>> Namespace documents seem like a good idea in contexts where there
>> is a 1:1 relationship between namespace and model or namespace
>> and vocabulary, but it will not scale as would be needed for
>> a trully global solution.
>
> It might not meet some needs but 1:1 relationships between namespace 
> and (evolving, but slowly) vocabulary is the very vast majority of 
> cases. They hit the sweet spot nicely.
>

Actually, they don't. Please see my other comments about
management scalability and ambiguity due to the one to many
mapping from term to model.

>> E.g. something analogous to <?xml-stylesheet ...?> is an option:
>> <?xml-model href="http://some.org/some/model/some/version"?>
>
> Anything that requires users to type in the above with no obvious 
> benefit to them cannot work.
>

That would be autogenerated by a tool -- or by a user who
knows what they are doing -- the the obvious benefit is that
their data will be more reliably consumed because they have
been explicit about the model(s) by which their information
should be interpreted.

The user benefit will be determined along the lines of more
reliably browser behavior, more useful functionality, and
more effective applications deployed -- because XML processors
have more explicit and reliable information about how to
process the data they encounter.

>> It also helps the "islands of XML" problem where different
>> XML languages are intermixed (e.g. XHTML+MathML+SVG) such
>> that the model identified constitutes a particular application
>> of those XML languages where the rules for conflict resolution
>> and other integration issues are defined for the model, and
>> applications supporting the model will then know how to
>> properly interpret the data instance.
>
> I strongly doubt that the problem of compound documents can be made to 
> be that simple :)

But it would be. The key problem with compound documents is knowing
how to properly interpret them, if/when there are ambiguities
or conflicts between the fused models. By defining a higher level
model which incorporates the individual models as components,
and specifies how ambiguities/conflicts should be resolved, the
agent is provided with an explicit solution.

Yes, there are still challenges, but focusing on the overall
model governing the creation and interpretation of the data
instance is the key to the solution.

Getting sidetracked by syntax issues will only delay a solution.

>
>> So, in short, namespace documents and RDDL are IMO searching
>> for one's lost keys under the street light because that's where
>> one can see. It misses the essential points that (a) namespaces
>> really are just syntax,
>
> Syntax with a convenient choice in the form of URIs.

IMO, it was a mistake to choose URIs. It would have been far
less painful if e.g. UUIDs would have been used. Or alternately,
treating namespace names as an alternate syntax for ENTITY
declarations -- such that all that ended up in the DOM were
complete URIs for terms, not qnames.

>
>> (b) from a management perspective,
>> trying to manage references to related resources in a single
>> document is highly impractical and non-scalable, and
>
> Again, for the large majority of cases it's highly practical and 
> trivial to scale.

I disagree. It will only work well for tiny, toy systems where
there is absolute control by a single owner over everything. It
is a hinderance to reuse and collaboration.

> I'm sure there are cases that are not covered by this approach, but 
> the degree of complexity at which an RDDL document becomes 
> insufficient likely corresponds to a level at which users are willing 
> to pay the price of a more complex solution — and conversely anything 
> that requires anything more complex than RDDL will have too high a 
> cost for people with simple needs to bother producing it.

What I'm proposing is actually *simpler* than RDDL namespace documents
accessed via namespace name URIs.

Name each top level model with a URI, and indicate that URI with each
data instance, and directly obtain the model-specific information
needed to interpret the data. Simple. Efficient. Explicit. Backwards
compatible.

Patrick


>
> -- 
> Robin Berjon
>   Research Scientist
>   Expway, http://expway.com/
>
>

Received on Friday, 18 February 2005 12:36:17 UTC