Re: XML Namespaces vs. RDF

Before responding to Dave's excellent points, I'd like to cut to the chase
and say what I would like to see happen, assuming my concerns are proven
valid.

Concatanation is a handy processing mechanism, and in practical use there
won't be an issue, so I'm not advocating abandoning concatanation.  However,
I'm concerned about the ambiguity caused by concatanation.

Assuming that all RDF/XML serializations must satisfy all compliance
requirements of the XML namespace spec, particularly the 5.3 Uniqueness of
Attributes constraint, concatanation could cause problems.  I give an
example below for how concatanation might lead to false reports of
conformance violations.  The RDF spec should note this potential problem.

More importantly, the RDF spec should add an additional requirement over all
of the formal grammar productions based on Qname, propName in particular.
The requirement should be modelled on the 5.3 Uniqueness of Attributes
constraint, only applied to element names and defining equivalence rather
than constraining uniqueness, again using the methods of A3. In other words,
equivalence should be tested prior to concatanation.

It is only with these additions that I think RDF developers can safely use
concatanation as a processing mechanism.

"HOLLANDER,DAVE (HP-FtCollins,ex1)" wrote:

> No, not only is A3 non-normative, it does not describe processing.

I'm still willing to be convinced that I'm reading too much into A3. 
However, I'm not quite there yet.  Here's the key text from A3:

	For convenience in specifying rules and in making comparisons,
	we define an expanded form, expressed here in XML
	element syntax, for each element type and attribute name
	in an XML document.

I read "specifying rules and in making comparisons" as "for processing". 
But maybe instead I'm supposed to read it as "with respect to the normative
part of this specification", which does make sense.  A clarafication by one
of the editors here would be helpful.

However, now we have another problem. This supposedly non-normative section
sneaks into the normative part of the spec by way of A.4, which says:

	The constraint expressed by "5.3 Uniqueness of Attributes"
	above may straightforwardly be implemented by requiring that
	no element have two attributes whose expanded names are
	equivalent, i.e. have the same attribute-value pairs.

This tells me that equivalence (the flip side of uniqueness) must be tested
prior to concatanation, at least for attributes.

The following example satisfies the 5.3 uniqueness constraint, i.e., that
the attributes are unique by following the method described in A3:

<anElement xmlns:foo="123abc" xmlns:bar="123">
	<uniquep foo:XYZ="true" bar:abcXYZ="false"/>
</anElement>

If this is true, the RDF spec needs to say more about testing for uniqueness
before concatanation is used, otherwise an RDF processor might claim that
the above example FAILS the uniqueness of attributes constraint!

Perry

Received on Wednesday, 21 July 1999 14:53:43 UTC