Issue http://www.w3.org/2000/03/rdf-tracking/#rdfms-not-id-and-resource-attr

Another attempt after previous threads:
  http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001May/0088.html
  http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001May/0050.html

RDF M&S provides valid (if rather unclear) definitions of how to
interpret an rdf:ID in a propertyElt in two cases, when the element
is empty / non-empty.  This answers the issue which asked why both ID
and resource were not allowed on an empty element - there is a
reason, and I point to it in the previous message.

I feel that changing this definition to make it consistent with other
parts of the syntax is not a good enough reason given that existing
parsers may have implemented it.


However, I have thought of another problem. XML parsers (I think) are
not required to let applications distinguish between:

  <elm/>
and
  <elm></elm>

The only reference I can find to it is:

  Appendix D: What is not in the Information Set
  7. The difference between the two forms of an empty element: <foo/>  and <foo></foo>.
  --  XML InfoSet  http://www.w3.org/TR/xml-infoset/#omitted


In at least two common XML X parsers I have used (expat and libxml),
these cannot be distinguished, they both return the same two
events/callbacks: start element, end element.

Since many systems use these as the standard XML parsers (this
includes Perl, Apache, Python, GNOME) they thus may not be able to
distinguish
  <prop:name rdf:ID="foo"/>
and
  <prop:name rdf:ID="foo"/></prop:name>
so RDF applications of these systems cannot make any decision based
on this either.

I feel that if this impacts any part of the RDF syntax that has a
dependency on the distinction, it should be changed - and that
includes this case.  This is a much better reason to change
- cannot be implemented in practice.

For this reason I would propose that we make a change here that is
implementable and consistent with the outcome of the
  Issue http://www.w3.org/2000/03/rdf-tracking/#rdfms-empty-property-elements
owned by Jan Grant.
and this issue should be on hold until that one is resolved.

Over to you Jan...

Dave

Received on Thursday, 24 May 2001 08:07:56 UTC