Comments on Fragment Identifier draft

I realize that I've missed the end of the LC period, but maybe it's still of use... Below some comments on the Last Call WD at
http://www.w3.org/TR/2012/WD-fragid-best-practices-20121025/


1. The terms “generic processor” and “generic processing” are used many times throughout the document, and much of the discussion hinges on these terms. For example, Best Practice 1 can be interpreted quite differently depending on whether one considers a generic RDF processor as a “generic processor” in the sense that is used in this draft. (I think an RDF processor is not a “generic processor” in that sense.) Therefore I think the term should be *explicitly* defined and hyperlinked. 


2. A comment on this quote:

[[
If the syntax of a syntax-based fragid structure overlaps with that of a semantic fragid structure, they cannot be used together, which constrains how they might be used.
]]

I don't think that statement is true. In what sense can they not be used together? This applies to RDF/XML, which in my eyes uses both a syntax-based fragid structure (xml:id) and a semantic one (that defined in RDF Concepts [1]) without trouble.


3. A case that doesn't seem to be covered is that of embedding one fragid-using format into another. This comes up in RDFa, which can be embedded in HTML and in XML formats, and uses fragids in ways that can clash with the host language. I don't know if this situation occurs with other technologies, so maybe it's not a common enough problem to justify inclusion in this finding.

I guess that advice similar to Best Practice 10 would be applicable in this case.

FWIW, here's what RDF-WG intends to say in RDF 1.1 Concepts about this:

[[
In cases where other specifications constrain the meaning of fragment identifiers in RDF-bearing representations, the encoded RDF graph should use fragment identifiers in a way that is consistent with these constraints. For example, in an HTML+RDFa document [HTML-RDFA], the fragment chapter1 may identify a document section via the semantics of HTML's @name or @id attributes. The IRI <#chapter1> should then be taken to denote that same section in any RDFa-encoded triples within the same document. Similarly, if the @xml:id attribute [XML-ID] is used in an RDF/XML document, then the corresponding IRI should be taken to denote an XML element.
]]


4. I tried to follow along with this example by looking up the relevant specs at IETF and W3C:

[[
For example, the media type registration for application/rdf+xml must include fragid rules that adhere to those specified in the +suffix registration for +xml. If a application/rdf+xml document contained an element with a @xml:id attribute with the value me then the fragid #me would be interpreted as referring to that element by generic XML processors. It would be inconsistent for other applications to interpret the #me fragid to refer to a person, and the media type registration for application/rdf+xml should not allow such an interpretation.
]]

Basically, the line of reasoning that leads to this conclusion is *very* thin, and barely held together by proposed but not-yet-accepted IETF documents, links to expired drafts, documents with ten-years-outdated information, and an appeal to “mechanisms outside the scope of this specification”.

Especially the fact that the entire +suffix registry seems to be still a draft shakes my confidence in accepting the proposed Best Practices as such.

I think the document should address more clearly the current state of things at IETF.


5. Appendix B.5, Semantic Content, can be confusing at first, as it has removed the @id attributes that were present on the bars in all previous examples. It would be clearer if it drew attention to the removal, perhaps by pointing out that having @id="hermione" on a bar would now be an error as that would assign the same identifier to a person and a document part. (This is actually another instance of the issue I mention in comment 3 above.)


6. The Best Practices Summary in Section 3 doesn't say who is supposed to follow each practice. This reduces the usefulness of the summary, and can in fact make it misleading. Breaking the list into parts ("For media type registrations", "For +suffix registrations", etc.) would solve this problem.


7. Overall this is a very clear document that pulls together lots of scattered information, organizes it well, and derives actionable recommendations. Nice!


Best,
Richard


[1] http://www.w3.org/TR/rdf-concepts/#section-fragID

Received on Wednesday, 19 December 2012 16:11:10 UTC