W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > March 2008

super easy issues: ISSUE-93, ISSUE-94, ISSUE-95, ISSUE-96

From: Ben Adida <ben@adida.net>
Date: Mon, 03 Mar 2008 21:33:28 -0800
Message-ID: <47CCDF28.6070800@adida.net>
To: RDFa <public-rdf-in-xhtml-tf@w3.org>


Shane has raised and immediately proposed simple resolutions to a number 
of small editorial issues. These should be trivial to accept. Please 
read and send +1 or -1:

==============
http://www.w3.org/2006/07/SWD/track/issues/93

In Section 5.5, processing rule 4, it says "If no URI is provided by a
resource attribute, then..."

This is a little confusing, since we of course have an attribute named
"resource".  What is meant is "If no new subject URI is obtained via
these rules, then..."  I hope, anyway.
==============


==============
http://www.w3.org/2006/07/SWD/track/issues/94

In section 5.5 Sequence, processing rule 13 (really rule 12) it says "a
value of 'true' should be returned from this level of processing.
Otherwise a value of false should be returned."

Two things:

1) change false to 'false' or change 'true' to true.
2) change should to MUST.  This section is normative, and that is a
conformance requirement.  The use of "should" is polite, but not what is
intended I think.
==============


==============
http://www.w3.org/2006/07/SWD/track/issues/95

Section 5.4 paragraph 3 reads:
"For example, the full URI for Albert Einstein on DPPedia is:"

It should of course be
"For example, the full URI for Albert Einstein on DBPedia is:"
==============


==============
http://www.w3.org/2006/07/SWD/track/issues/96

Section 5.4.3 reads (in part):

There are a number of ways that attributes will make use of CURIEs, and
they need to be dealt with differently. These are:

    1. An attribute may be CURIE-only, disallowing other types of values.
       In this case any value that is not a 'curie' according to the
       definition in the section CURIE Syntax Definition
       <http://www.w3.org/TR/rdfa-syntax/#s_curies> should not affect
       processing in any way; this means that not only will there be no
       error reporting, but also the RDFa processor should act as if the
       value simply did not exist.
    2. An attribute may allow CURIEs, as well as a full URI. In this case
       any value that is not surrounded by square brackets, as defined by
       'safe_curie' in the section CURIE Syntax Definition
       <http://www.w3.org/TR/rdfa-syntax/#s_curies>, will be processed as
       if it was a URI. If the value /is/ surrounded by square brackets,
       then the inner content must conform to the 'curie' definiton, and
       as before, if it does not then the value should have no effect on
       processing.

Since this is normative content, the shoulds in need to be "MUST".
Second, "no effect on processing" is a little ambiguous for my tastes.
I would prefer "be ignored".  So, these clauses could read:

There are a number of ways that attributes will make use of CURIEs, and
they need to be dealt with differently. These are:

    1. An attribute may be CURIE-only, disallowing other types of values.
       In this case any value that is not a 'curie' according to the
       definition in the section CURIE Syntax Definition
       <http://www.w3.org/TR/rdfa-syntax/#s_curies> MUST be ignored; this
       means that not only will there be no error reporting, but also the
       RDFa processor MUST act as if the value simply did not exist.
    2. An attribute may allow CURIEs, as well as a full URI. In this case
       any value that is not surrounded by square brackets, as defined by
       'safe_curie' in the section CURIE Syntax Definition
       <http://www.w3.org/TR/rdfa-syntax/#s_curies>, will be processed as
       if it was a URI. If the value /is/ surrounded by square brackets,
       then the inner content must conform to the 'curie' definiton, and
       as before, if it does not then the value MUST be ignored.
==============

-Ben
Received on Tuesday, 4 March 2008 05:33:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:55 UTC