- From: Perry A. Caro <caro@Adobe.COM>
- Date: Wed, 21 Jul 1999 11:52:49 -0700
- To: rdf-dev@mailbase.ac.uk, www-rdf-comments@w3.org
- CC: xml-names-editor@w3.org
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