Re: ISSUE-67 triage

Toby,

I somehow missed that you had sent these detailed instructions.  My 
comments / actions below:

On 1/25/2011 5:16 PM, Toby Inkster wrote:
>
> Editorial Fixes
> ===============
>
> HS: It seems questionable that formsplayer.com (site of a product that
> one of the Editors has a commercial interest in) is used in an example.
>
> TI: Please replace with something like example.com. [EDIT]

Done

> HS: The Creative Commons license example in section 2.2 uses the
> anti-pattern of saying "a Creative Commons license" (instead of saying
> which one of the numerous licenses) in the human-readable prose.
>
> TI: Please include the name of the license in this example - possibly
> mark it up in RDFa as the license's dc:title or rdfs:label. [EDIT]

I added the type to the license text.  I didn't want to complicate the 
example further.

> HS: The processing model for the case where the optional xmlns:prefix
> feature is supported isn't specified.
>
> TI: Step 4 in the processing sequence could be expanded upon. Need to
> indicate that @xmlns:* is processed first, if permitted by host
> language; then @prefix which can override the previous mappings from
> @xmlns:*. [EDIT]

I added text to clarify this.

> HS: It's weird that the prefix attribute requires a single space between
> the colon following the prefix and the URI but allows multiple spaces
> between the URI and the next prefix.
>
> TI: This seems to be a mistake. We should allow one or more whitespace
> characters in both cases. We need to make sure the regular expression or
> algorithm for extracting mappings from @prefix can cope with that (see
> next question). [EDIT]

Done

> HS: If the spec contains rules for how to extract a set of prefix to URI
> mappings from the prefix attribute, the rules are hard to locate.
>
> TI: We used to have a regular expression for parsing the prefix mapping.
> (Perhaps on the rdfa.info wiki?) Could this be added to RDFa Core, or as
> an alternative a detailed algorithm for parsing @prefix? [EDIT]

Well...  I mean, seriously.  We provide the eBNF.  splitting on white 
space seems like a well-understood idiom.  A similar attribute, 
xsi:schemaLocation, does not provide guidance on how to parse its 
content at all in the XML Schema part 1 recommendation.  Toby, if you 
feel this is important, can you provide some specific text and a 
location where it should go in the spec?  For now, I am leaving this alone.

> .......
>
> HS: Under 4.1 the statement about whitespace seems to say that authors
> should assume non-conforming processors.
>
> TI: Would anyone object to removing the second and third sentances from
> the last paragraph of section 4.1? [EDIT]

I have changed the text to make it clear what we *meant* by this 
clause.  I think it is an important point.  It now reads:

<p>A conforming RDFa Processor must preserve white space in both 
<tref>plain literal</tref>s
   and <tref title="xml_literals">XML literals</tref>. However, it may 
be the case that the architecture in which a processor operates has made 
changes to the white space in a document before that document ever 
reaches the RDFa Processor (e.g., [[XMLSCHEMA-1]] processors are 
permitted to 'normalize' white space in attribute values - see section 
3.1.4).
To ensure maximum consistency between processing environments, authors 
SHOULD remove any unnecessary white space in their plain and XML Literal 
content.</p>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Friday, 18 February 2011 21:40:23 UTC