Re: [xml-dev] Re: URIs, concrete (was Re: [xml-dev] Un-ask the question)

["Simon St.Laurent" <simonstl@simonstl.com>]

> >> To put it bluntly, I'm saying that NO ONE EVER SHOULD CREATE MARKUP
> >> WHICH FOLLOWS THIS PATTERN:
> >> 
> >> <rdf:Description rdf:about="http://www.w3.org";
> >> about="http://www.w3.org/not/really/I'm/just/kidding/">
> 
> What do you think of the situation where x:m attribute in <x:a
> x:m='1'/> and <x:b x:m='1'/> mean something completely different?
> This seems to be where you are going to wind up.

I think that's a different problem than what I'm describing, and I'm not
quite sure what you mean here.  Are you saying that the meaning x:m
should be the same in both cases because it looks like a global
attribute?  Or are you saying that forcibly namespace-qualifying
attributes (something I'm not proposing) is wrong?

 
> Does anyone notice anything wrong here? Why am *I* having to work out
> an interpretation of namespace qualified attributes that works?

Yep.  That's the largest single problem with all this.

> What if you looked at attributes in this way:
> 
> 1) all attributes describe the element in which they appear
>
> 2) the meaning of descriptions provided by attributes that are not
> namespace qualified is dependent upon the element
>
> 3) the meaning of descriptions provided by namespace qualified
> attributes is independent of the element (I'd argue that this means
> that a namespace qualified name should be interpreted in the same way
> where ever it appears.)
> 
> Is there something wrong with this? I think the disagreements will
> start with 3). Does it conflict with the spec? What happens in RDF?
> XSL?

If you reserve explicit namespace-qualification in the document to
global attributes, I think we're just fine.  RDF namespace-qualifies
everything, so I think there's a problem with (3) there.  XSLT also
treats namespace-qualified attributes slightly differently.

> Importantly, <a m='0'/> and <x:a m='0'/> are the same.

In the case where the default namespace declaration and the xmlns:x
declaration reference the same URI, sure.  Otherwise, I'm not so sure.

> Without further information, not only is <x:a m='0'/> and <x:a
> y:m='0'/> different, but <x:a m='0'/> and <x:a x:m='0'/> are
> different (lets say that there are no default values supplied by some
> sort of schema, that x and y signify different namespaces, etc.).
> Then also in <y:a x:m='1'/> and <z:b x:m='1'/> the interpretation of
> x:m in independent of the element (and I think should be
> consistent/the same/related) though it still applies to that element.
> 
> This means that <x:a m='0' x:m='0' y:m='0'/> is possible and has a
> reasonably straightforward interpretation -- or at least it has an
> interpretation that doesn't trigger a gag reflex in me. It even works
> for <rdf:Description rdf:about="http://www.w3.org";
> about="http://www.w3.org/not/really/I'm/just/kidding/">

I think this is where I get off your train completely.  That DOES
trigger a gag reflex in me, almost as strong a reflex as W3C XML
Schema's monkeying around with unqualified "local" elements.  It's
POSSIBLE to create an interpretation that tolerates that circumstance,
but I don't believe it's at all reasonable.

> This interpretation allows that with specific additional knowledge
> (or agency, whatever) it might be that <x:a m='0'/> and <x:a
> x:m='0'/> are interpreted as being the same, but you can't tell by
> looking at just the XML.

If you can't tell just by looking at the XML at this level, I'd say we
have some very ugly application-specific dependencies that will cause
grief over the long run if that XML ever has to visit a different
application.

> I agree that we should be avoiding un-necessary confusion with names,
> even given this interpretation. And this is something that you'd
> think the designer would have had control over. But things do evolve.
> And they evolve while choosing attribute names from a natural
> language with homonyms. Anyways, given this interpretation, this is a
> 'should not' not a 'must not'. Choosing the right name for the
> attribute might illustrate how this could happen, but I can't think
> of a good example, perhaps <x:data valid='false' x:valid='true'/>?

I think in this case it's time for evolution to proceed by cutting off
one possible path for the preservation of the rest of the paths.
 
> I guess, this view has it that the 'm' part of the attribute should
> not be seen to have meaning on its own. Just because 'm' is shared
> between them, there isn't any common meaning necessary between
> 'x:m="1"' and 'y:m="1"' (where x and y denote different namespaces).
> Local names and unqualified names are not comparable (in any
> combination)? Though it may well be misleading to a human reader and
> so a bad practice.

It's misleading to humans and ambiguous to computers.  I don't find
either of those to be good things.

> So, once again, what do you think of the situation where x:m
> attribute in <x:a x:m='1'/> and <x:b x:m='1'/> has completely
> different meaning? If <x:a m='1'/> and <x:a x:m='1'/> are the same,
> then this is what you get. Or are you thinking that the 'm' attribute
> in <x:a m='1'/> and <x:b m='1'/> should be related?

I still don't see what you're asking in this question.

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com