Lists Home |
Date Index |
Walter Perry wrote:
> email@example.com wrote:
> > Just to hammer this point again. There is no requirement to be different. An
> XML Namespaces conformant application might or might not act differently and
> still properly claim conformance. Said another way, even though the range of
> interpretations are _not required_ to be the same, they might be.
> So is it not then as I initially wondered, that in elaborating semantics through
> the processing of attribute instances, the element to which an attribute is
> attached may exert such influence that there is no discernible difference in the
> semantic outcome of process, regardless of what namespace an attribute might or
> might not be in?
for example a template in a stylesheet _might be_
<xsl:template match="foo:bar[@baz | @*:baz]">
and treat the attribute "baz" the same as any namespace qualified attribute "ex:baz" ...
> Or again, in other cases of process, the attribute namespace
> might be decisive and result in discernible differences in outcome?
right so you might also do:
<xsl:template match="foo:bar[@baz]"> ...
<xsl:template match="foo:bar[@foo:baz]"> ...
<xsl:template match="foo:bar[@*:baz]"> ...
> the sense in which Simon's suggestion is "wrong", as Tim asserts, is that it
> violates a distinction maintained in the formalism of namespaces, but in the > terms in which it is offered (how to treat an attribute, presumably in
> processing it), Simon's suggestion may often, in fact, be the best practice,
> perhaps even the only practice actually
> processable in the instance.
Simon's distinction is not "wrong" it is just not "required". His recommendation would look like:
<xsl:template match="foo:bar[@baz | @foo:baz]"> ...
> I began this by wondering whether the concept of 'in a namespace' had more than
> evanescent effect upon attributes as processed, particularly as compared with
> the influence exerted by an element because of the attribute's necessary
> dependence on it. I am increasingly convinced that the 'namespace' qualities, or
> namespace-derived properties of attributes cannot be identified in the general
Correct in the "general case" the namespace name is there for a program to process as it wishes. One _might_ dereference a namespace URI and look for some information that one _could choose to_ apply to the processing of a piece of XML (perhaps if a namespace name represented itself as a RDDL document) but this _is not required_ of either the namespace nor of the processor.