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

Jeni,

More thoughts in line.  I am out of position the remainder of today.

Jeni Tennison wrote:
> Shane,
>
>
> When you say "as if the attribute was never there" you do mean the 
> datatype attribute, right? So you're saying that:
>
>   <span about="#shane" property="foaf:name" 
> datatype="blah:blah"><em>Shane</em></span>
>
> should be interpreted as if it was:
>
>   <span about="#shane" property="foaf:name"><em>Shane</em></span>
>
> and therefore create the triple:
>
>   <#shane> foaf:name "<em>Shane</em>"^^rdf:XMLLiteral
>
> ?
Huh.  No, I didn't *mean* to say that.  However, yes, that is what my 
interpretation would logically generate.  That's not cool.
>
> Personally, I think it's more surprising for the mistakenly invalid 
> datatype attribute to cause the creation of an object with the 
> datatype rdf:XMLLiteral than a plain literal.
>
> I have absolutely no problem with the outcome of generating no triple 
> at all. But to get that, you can't just "behave as if the datatype 
> attribute isn't there" (since that leads to the rdf:XMLLiteral). I 
> think that you need to amend the description in Step 9 to explicitly 
> introduce the possibility of the datatype attribute holding an invalid 
> value and say that this causes there to be no [current object literal] 
> and thus no triples generated from the properties.
Yeah.  My simple, general approach to this isn't going to work.  
Actually, as written the current rules already do exactly what we want 
in step 9.  But it isn't explicit.  It's an *indented* consequence of 
the rules being written the way they are.  But, and this is the 
important bit, only if you read the sub-steps of step 9 as being 
mutually exclusive (e.g., if this, else if that, else if the other.  
That's what they are supposed to be read as, but I could see someone 
reading them as independent clauses so that the process of evaluation 
@datatypes content forces @datatype to be "", which then causes a plain 
literal to be generated via step 2.

So.... yes, I know what we meant when we wrote it.  And yes, it is 
possible to interpret the spec that way.  But yes, it is also possible 
to interpret it the other way, and we should clarify this in an errata 
and ultimately with an update to the spec.  Thanks for pointing out my 
mistake!
> ....
>
> On what basis? The hanging triple has to be completed one way or the 
> other doesn't it? Either it's completed with a bnode (if the illegal 
> property sets [skip element] to false) or with <http://example.net/> 
> (if the illegal property doesn't set [skip element] to false).
>
> Or, again, there needs to be additional language in the specification 
> that says that if the property attribute is present but holds no legal 
> values then the hanging triples are dropped on the floor.
>
> I think Mark's argument about the interpretation of rel attributes 
> applies here as well. He argued:
>
>> The final piece of the jigsaw is to bring back in the earlier point,
>> i.e., that the spec allows us to create a triple from 'foobar'
>> provided that we don't put it into the default graph. In this case my
>> parser might place the 'unknown' triple into a separate graph:
>>
>>  Default graph:
>>    _:a foaf:name "Mark" .
>>
>>  Graph A:
>>    <#shane> ex:blah _:a .
>
> In the case of
>
> <p xmlns:ex="http://example.org/" about="http://example.com/" 
> rel="ex:rel3">
>    <span property="bogus:bogus" content="Content 3">
>      <span about="http://example.net/">Test 3</span>
>    </span>
>  </p>
>
> by the same argument, we should create:
>
> Default graph:
>   <http://example.com/> <http://example.org/rel3> _:a .
>
> Graph A:
>   _:a bogus:bogus "Content 3" .
>
> To do this, the property attribute must be treated as "present" rather 
> than as "not present" (ie as if the property attribute wasn't there).
Well... this presumes that you are creating an alternate graph.  If you 
want to do this in your implementation, you are free to do so.  A 
Conforming RDFa Processor is not required to do this.  As to the "basis" 
for my conclusion...

Processing step 8 reads, in part:

If however [current object resource 
<http://www.w3.org/TR/rdfa-syntax/#T_current_object_resource>] was set 
to null, but there are predicates present, then they must be stored as 
[incomplete triple 
<http://www.w3.org/TR/rdfa-syntax/#T_incomplete_triple>]s, pending the 
discovery of a subject that can be used as the object. Also, [current 
object resource 
<http://www.w3.org/TR/rdfa-syntax/#T_current_object_resource>] should be 
set to a newly created [bnode <http://www.w3.org/TR/rdfa-syntax/#T_bnode>];

This means that while a bnode must be *named* at this time, the 
corresponding triple would not be included in the default graph unless 
the bnode is actually resolved by attaching it to something else during 
the recursive processing of the child elements.

Basically, the task force discussed and to my recollection concluded 
that emitting "useless" triples was not desirable.  If there are no 
triples emitted during the recursive processing of the child elements, 
then the pending bnode triple is "useless" and should be dropped.  
Obviously, if your implementation is preserving non-conforming triples 
in an alternate graph, this triple may not be "useless" and you might 
want to preserve it.  I am not sure which graph I would emit it in were 
I to implement something similar.


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