- From: RDFa Working Group Issue Tracker <sysbot+tracker@w3.org>
- Date: Tue, 04 Jan 2011 03:01:38 +0000
- To: public-rdfa-wg@w3.org
ISSUE-71 (Core - Shelley Powers): RDFa Core 1.1 LC comments from Shelley Powers [LC Comment - RDFa Core 1.1] http://www.w3.org/2010/02/rdfa/track/issues/71 Raised by: Manu Sporny On product: LC Comment - RDFa Core 1.1 >From Shelley Powers: I have no suggestions for tangible changes to the RDFa core. I feel that the existing attributes and their usage has been explained sufficiently, and there are no inconsistencies. I really like @profile, though I know it caused some very valid concerns at one point. However, you did address the concerns in the document. The only thing I would suggest is ensuring that RDFa authors are aware of the potential problems with profiles and the use of scripting to perform RDFa processing. But since the author controls both (the use of the script and the use of profile), they do control the solution. The only remarks I have are more about the readability of the document. As such, they are more suggestions rather than specific requests. The only item would strongly advise you to consider is bringing in an accessibility expert, because of the frequent use of visual cues. RDFa review In Section 2.2 Examples, you mention the link and meta elements, but in the section following you reference them as a "concept" but the concept was never explained. The transition was confusingly abrupt. Especially going right into CURIEs. In the following example, you use a CURIE, but again the transition is lost because of the brevity of the explanation leading into the example. I'm also a little concerned about the use of color highlighting. From an accessibility stand point you may want to also make the text bold. In addition, though I don't know if you want to be this verbose, you may want to include a reference to the item of importance in the example, so that those using a screen reader aren't left to guess what's important in the example. For instance, instead of the following sentence: In many cases a block of markup will contain a number of properties that relate to the same item; it's possible with RDFa to indicate the type of that item... Use: In many cases, a block of markup contains a number of properties that relate to the same item. You can use the RDFa typeof attribute to indicate the type of that item... By providing a hint about what's important in the following example, not only do you provide an additional assistance to those without visual impairment, you're also providing the only clue for those using a screen reader. The examples also reference terms that are defined later in the document, such as using triples. For your audience, I don't know if you need to ensure clarify to a newcomer to RDF, but you might want to provide a brief explanation, just to ensure that a person doesn't get lost. Moving on... The RDF terminology section is excellent. In the conformance section, you mention about authors needing to ensure they remove unnecessary white space, but I'm not sure the authors are going to see this section. Perhaps an example earlier? Just to ensure all audience members see this critical information? Sections 4 though 6 were good: succinct, providing just enough algorithm to ensure consistency, without pedantically overstating the steps. In section 6.1, I realize that this section is targeted at the person asking, "Why not QNames?", but others could benefit from the discussion. To ensure everyone has the same background entering the section, perhaps a brief explanation of what is a QName? The Chaining section was excellent. The only thing I would say about the examples is that the spans would most likely contain actual visible text, though that data isn't of matter to the person or people writing the processor. This is covered in the earlier examples, but redundancy can't hurt. The RDFa processing rules, followed by the section on Processing in Detail is also very well done. The Processing in Detail was a spot on idea--rather than break flow by inserting examples into the more detailed implementation specific section, provide the clarifying section as a follow up. Overall, very well done. The only other recommendation I would make would be to have an accessibility expert review the use of visual elements as indicators, to ensure there's enough other material provided so that a person with visual challenges can also understand all the important bits.
Received on Tuesday, 4 January 2011 03:01:40 UTC