Re: Comments on Fragment Identifier draft

Hi Richard,

On 19 Dec 2012, at 16:10, Richard Cyganiak <richard@cyganiak.de> wrote:
> 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/

Thank you for commenting! :) A new editors draft is now available at:

  http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2013-01-05.html

which incorporates your comments as below.

> 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. 

OK. I have added "generic processor" and "generic processing" as defined terms.

> 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.

I wouldn't say "without trouble" but OK, I have merged that sentence with the next to read:

  "If the syntax of a syntax-based fragid structure overlaps with that of a 
   semantic fragid structure, or if the syntax of two semantic fragid structures 
   that could both apply to a given media type overlap and identify different 
   things, the media type will have to specify which takes precedence during 
   fragid processing."

> 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.

The media type is the only thing that determines how fragids are interpreted. If RDFa attributes were used in a particular XML vocabulary for which a media type was registered (eg application/docbook+rdfa+xml or something) then that media type could specify particular handling for fragids.

Other than that kind of example, which is covered by the existing guidance I think, while RDFa might embed references to URIs that include fragids within the attributes it uses, it's not a media type and therefore cannot define how fragids are interpreted within documents that it is used in.

Am I missing something? What kind of Best Practice would you suggest to cover the RDFa case?

> 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.
> ]]

Yes, that looks good. The media type definition for text/html has to be the determining factor for how fragids on text/html documents are interpreted.

> 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.

I think Henry addressed this in his response. By the time this document is published as a Recommendation, the relevant IETF RFCs will have been updated.

> 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.)

OK. I have added a note to highlight this.

> 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.

The Best Practices Summary is automatically generated by Respec so I can't do much about its structure. However, I've reworded the labels for the Best Practices so that they include information about the applicability of each, which I hope helps.

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


Thanks :)

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com/

Received on Saturday, 5 January 2013 21:54:56 UTC