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

Hi Ben,

The last one is not so super easy. :)

>  ==============
>  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.
>  ==============

+1


>  ==============
>  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.

+1


>  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.
>  ==============

+1


>  ==============
>  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:"
>  ==============

+1


>  ==============
>  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.
>  ==============

-1

We've gone to great lengths to allow RDFa parsers to generate extra
triples if they like, the only condition being that they don't appear
in the [default graph]. So I used the terms "no effect on processing"
and "act as if the value simply did not exist" as a way to try to
indicate that as long as the full processing rules were observed, you
could do what you liked.

Saying that extra values in @rel "MUST be ignored" would not achieve
this, and would actually prevent a processor from doing _anything_
with the values.

Which is not to say that there might not be better wording than
"should have no effect on processing" and "act as if the value simply
did not exist"--I'll leave that for others to decide; but "MUST be
ignored" would not capture what I was trying to do in this section.

Regards,

Mark

-- 
  Mark Birbeck

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.x-port.net | http://internet-apps.blogspot.com

  x-port.net Ltd. is registered in England and Wales, number 03730711
  The registered office is at:

    2nd Floor
    Titchfield House
    69-85 Tabernacle Street
    London
    EC2A 4RR

Received on Friday, 7 March 2008 12:03:41 UTC