Re: Agenda Topic / Issue: Clarify the meaning of "ignore" with respect to attributes that have no legal value

Mark,

There's a lot in here. Forgive me if I collapse out some bits.

Mark Birbeck wrote:
> Hi Shane,
>
> I'm not convinced there is a problem here.
>   
I didn't mean to imply that there was a problem at all.  I think the 
spec is fine.  I just wanted to clarify our intent with some explicit 
language because some people have expressed confusion over how certain 
edge conditions should be treated.  I believe those edge conditions are 
all dealt with already in the spec, but perhaps using language that is 
not crystal clear if one were not the author :P
> We don't talk about "illegal" values in the way that you are implying
> -- all we talk about is whether triples find their way into the
> default graph, or not.
>
> To illustrate; in section 5.4.4 we have this example:
>
>   <link rel="foobar" href="http://example.org/page7.html" />
>
> and we point out that this will not generate triples in the default graph.
>
> But we don't say it won't generate any triples at all.
>   
In my haste to send out that note, I suspect I overgeneralized.  What I 
should have said is that the general rule I was describing is one that 
applies to a Conforming RDFa Processor in its generation of the default 
graph.  Of course we would not restrict what a processor might do in 
some other graph.

[deleting a bunch of text relating to graphs and about @rel/@rev and 
bnode generation]
> (Which is how the spec is currently defined, and why I don't think
> there is a problem.)
>   
I agree that the spec as written correctly deals with @rel / @rev, 
albeit in a more complex manner than the casual reader might 
appreciate.  (ooh! I got to use the word 'albeit'!)

> By the way, there is another reason I prefer the "present but empty"
> approach, and that's because it enables a simple construct that
> provides a convenient way to generate a bnode to attach 'stuff' to:
>
>   <span typeof="">
>     <span property="ab:cd">ef</span>
>     <span property="ab:gh">ij</span>
>   </span>
>
> which generates this:
>
>   _:a ab:cd "ef" .
>   _:a ab:gh "ij" .
>
> Unfortunately, the spec is not so clear here, and says in step 4:
>
>   if @typeof is present, obtained according to the section on CURIE and
>   URI Processing, then [new subject] is set to be a newly created [bnode].
>
> I think this is wrong, and doesn't fit with the spirit of @rel and
> @rev; it would be better off simply being:
>
>   if @typeof is present then [new subject] is set to be a newly created
>   [bnode].
Yes, this is one of the issues that Philip and others seem concerned 
about.  You and I know what we meant here, and I expect the test suite 
exercises what we meant (maybe not completely), but this language is 
misleading. 

Let's ignore @rel, @rev, and @typeof for a moment.  Those are for 
defining predicates, and we have clear rules for what happens if the 
list of predicates in a predicate-declaring attribute evaluates to the 
empty set (for the default graph).

Philip has pointed out, and I agree, that our language in a couple of 
places is inconsistent with regard to what happens if the contents of an 
attribute are invalid (or illegal - same thing).  I don't think the spec 
is wrong in any way, nor that we require any changes to the behaviors we 
KNOW we meant to define.  I also agree with your statement above that we 
don't talk about illegal values.  We don't use the term "illegal" or 
"invalid" at all in the RDFa Syntax specification.  However, section 5.4 
on CURIE and URI Processing defines the rules for processing CURIEs.  It 
says 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 allow one or more CURIE-only values,
>       disallowing other types of value. 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 should act as if the
>       value simply did not exist.
>    2. An attribute may allow one or more values that are a mixture of
>       CURIEs and full URIs. 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.
>
At issue is our inconsistent interpretation of what it means when ALL 
the values in an attribute declaration are ignored.  My proposal was 
meant to clarify what is already in the specification - although 
perhaps, as I said, I over-generalized.  My belief was that the 
specification as written *in general* requires that such attributes 
cause no triples to be raised. 

It is my belief that the following are NOT equivalent from a processing 
perspective (assume the foaf prefix is declared, the blah prefix is not):

   1. <span about="#shane" property="foaf:name" datatype="">Shane</span>
   2. <span about="#shane" property="foaf:name"
      datatype="blah:blah">Shane</span>

The first item explicitly requests a text literal.  The second item 
requests a datatype that is undefined (illegal, invalid, whatever).  I 
maintain that in a conforming processor the second item would NOT 
generate any triple.  I think the same is true for our treatment of 
@property, @about, and @resource.  It is explicitly NOT true for @rel, 
@rev, and (maybe) @typeof because of their ability to cause bnodes to be 
created.  Do you disagree?  And can you answer in one page or less? :P

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