Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: URIs, concrete (was Re: Un-ask the question)
 > >> 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
