ISSUE-71 (Core - Shelley Powers): RDFa Core 1.1 LC comments from Shelley Powers [LC Comment - RDFa Core 1.1]

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