OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] assigning semantics to XML, Re: [xml-dev] Re: URIs,

[ Lists Home | Date Index | Thread Index ]

Walter Perry wrote:
> John Cowan wrote:
> > It means that, under the Namespaces Rec, the following pair is equivalent:
> >
> >         <foo xmlns="urn:baz:32" bar="47"/>
> >         <baz:foo xmlns:baz="urn:baz:32" bar="47"/>

This isn't entirely correct because "[prefix]" is a element information item according to XML Infoset. 

I don't think XML Namespaces discusses element equivalence, so I will assume that we can say that "element equivalence" is determined by both elements having equivalent XML Infosets, i.e. the string information items are the equal, and child elements are equivalent. The most you can say is that both elements are in the _same namespace_. However XML Infoset _does_ say 

[[ Note that namespace-aware applications should use the namespace name rather than the prefix to identify elements. ]]

and so 'best practice' treat the elements as equivalent, that is to say: a 'best practice' semantics would apply the same range of interpretations to both elements. 

John, as the Infoset editor, shame on you :-))

> >
> > but the following pair is not:
> >
> >         <foo xmlns="urn:baz;32" bar="47"/>
> >         <baz:foo xmlns:baz="urn:baz:32" baz:bar="47"/>
> A distinction without a difference?
> Does this mean that, in practice, the distinction which you point to under the
> Namespaces Rec requires no difference in how instances are, in fact, processed?

No it doesn't say that. First of all, having a possible range of interpretations from which a given application might (or might not) assign a single interpretation, again, is different from _requiring all applications_ to assign the same interpretation. What the second example indicates is that an application _may or may not_ assign different semantics to each element as it chooses. If we say that the range of interpreations of both elements _may be_ different, to be clear, this does not _require_ that any particular interpretation be the same, one might have overlapping ranges, for example. 

My language may seem a bit formal, but I am trying to be precise about this.

> That Simon's suggestion to treat (for which I read, 'process') them as being in
> the namespace of the element that contains them is as good a way to proceed as 
> any
> other? 

Simon is providing _a suggestion_ that both should be assigned the same semantics i.e. range of interpretations. XML Namespaces, however, does not mandate this.

> Or that there is no consequence in processing (and therefore in the
> semantics ultimately elaborated in any instance) for making the distinction
> between an attribute being in no namespace versus being in the namespace of its
> element?

No. For a given application (i.e. in assigning a specific interpretation) there _might not be_ a distinction, but there also _might be_ for a different application. This should fix perfectly well with your oft stated position that "semantics is local". All I am saying is that a spec can be interpreted as limiting the _range_ of interpretations for a given syntactic structure. Again assuming that our applications are "XML Infoset" conformant, we do not assign different _ranges_ of interpretations whether or not single or double quotes are used to delimit attributes. No one is necessarily holding a gun to your head requiring your application to be XML Infoset conformant just because it is an XML application, but if you claim XML Infoset conformance, then you are limiting the range of interpretations of your XML.

> I began this wondering if there were any difference discernible in processing 
> and
> in the outcome of processing. Are you saying that there is none?

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.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS