- From: RDFa Working Group Issue Tracker <sysbot+tracker@w3.org>
- Date: Thu, 13 Jan 2011 04:48:22 +0000
- To: public-rdfa-wg@w3.org
ISSUE-75 (Core - Jeni Tennison 3): Specification Structure [LC Comment - RDFa Core 1.1] http://www.w3.org/2010/02/rdfa/track/issues/75 Raised by: Manu Sporny On product: LC Comment - RDFa Core 1.1 >From Jeni Tennison: My final general point is an editorial one: the spec contains the same (or similar) information in multiple places, and this can make it hard to work out where to look for given information and may mean that there are inconsistencies which are hard to identify. There are three specific cases where this is particularly bad. First, information about CURIEs is available in: * Section 3.8 Compact URIs (under 'RDF Terminology') * Section 6 CURIE Syntax Definition * Section 7.4 CURIE and URI Processing It would be good to integrate these, or at least the second two, into a single section. Second, information about the content of the different attributes is available in: * Section 5 Attributes and Syntax * Section 7.4.4 Use of CURIEs in Specific Attributes * Section 8 RDFa Processing in Detail as well as being implicitly scattered in Section 7.5 Sequence. I would like to see the normative definitions of the types of values accepted by the attributes in only one place (probably Section 5). Finally, information about how to process RDFa documents is defined in both: * Section 7.5 Sequence * Sectio 8 RDFa Processing in Detail When I was implementing RDFa 1.0, I found this particularly problematic. I ended up trusting Section 7.5 (or whatever it was then) and ignoring Section 8. What I would like to see is one of these sections becoming non-normative, so that there is a single authoritative place within the spec that defines how to process RDFa. FWIW, I generally prefer a declarative definition to a procedural one, but Section 8 is written more as a sequence of examples than a detailed definition of RDFa processing, so of the two I think that it should be the one made non-normative.
Received on Thursday, 13 January 2011 04:48:23 UTC