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


On 11 Sep 2009, at 20:41, Shane McCarron wrote:
> Jeni Tennison wrote:
>> On 11 Sep 2009, at 16:36, Shane McCarron wrote:
>> In the case where the element did contain elements:
>>  <span about="#shane" property="foaf:name"  
>> datatype="blah:blah"><em>Shane</em></span>
>> I think the fourth of the clauses -- "or the body of the [current  
>> element] does have non-text child nodes but @datatype is present,  
>> with an empty value." -- comes into action, because there is a  
>> datatype attribute present but it has an empty value (because its  
>> value is illegal). So we again get the triple:
>>  <#shane> foaf:name "Shane" .
> (thanks for fixing my example.  that's what I was driving at, but I  
> was working too quickly again!)
> And I disagree.  I don't think we SHOULD get that value.  I think  
> transforming an explicit datatype that was declared in error into  
> another datatype violates the principle of least surprise.  I think  
> that in this case, in the default graph, the processor MUST act as  
> if the attribute was never there.  Unlike @rel, there are no rules  
> that care about the presence of @datatype.  Specifically, I disagree  
> with your interpretation that the case of  "@datatype is present  
> with an empty value" is equivalent to "@datatype is present with an  
> illegal value".

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"  

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


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.

>> FWIW, I disagree about property, because it also has the power  
>> (through the setting of [skip element] in step 4) to determine  
>> whether or not bnodes are created to complete any hanging triples.  
>> This is Philip's example. With no property attribute:
>>  <p xmlns:ex="" about=""  
>> rel="ex:rel1">
>>    <span content="Content 1">
>>      <span about="">Test 1</span>
>>    </span>
>>  </p>
>> we should generate:
>>  <> <> <http:// 
>>> .
>> With a legal property attribute:
>>  <p xmlns:ex="" about=""  
>> rel="ex:rel2">
>>    <span property="ex:prop" content="Content 2">
>>      <span about="">Test 2</span>
>>    </span>
>>  </p>
>> we should generate:
>>  <> <> _:bnode1 .
>>  _:bnode1 <> "Content 2" .
>> The final example being an illegal property attribute which means  
>> that the property is still *present* (causing the creation of a  
>> bnode) but does not create triples of its own:
>>  <p xmlns:ex="" about=""  
>> rel="ex:rel3">
>>    <span property="bogus:bogus" content="Content 3">
>>      <span about="">Test 3</span>
>>    </span>
>>  </p>
>> we should generate:
>>  <> <> _:bnode2 .
> I disagree.  I believe it would generate nothing.

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 <>  
(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="" about=""  
    <span property="bogus:bogus" content="Content 3">
      <span about="">Test 3</span>

by the same argument, we should create:

Default graph:
   <> <> _: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).

>> It would make things clearer all round if the specification used  
>> phraseology that specifically included the possibility of illegal  
>> values and made it explicit where it's talking about *values* being  
>> present and where about *attributes* being present in relevant  
>> places, such as:
>>  "_the_ @datatype _attribute_ is present, and does not have an  
>> empty _or illegal_ value, and is not set to rdf:XMLLiteral."
>>  "or the body of the [current element] does have non-text child  
>> nodes but _the_ @datatype _attribute_ is present, with an empty _or  
>> illegal_ value."
>>  "Additionally, if _the_ @property _attribute_ is not present then  
>> the [skip element] flag is set to 'true';"
> Quite.  This is why I brought up the issue in the first place.  Or  
> rather, Philip did but I am trying to get it resolved.

I understand. I was concerned that your agreement with Mark's  
assertion that there is no problem meant you weren't going to clarify  
the wording. I look forward to seeing the errata.


Jeni Tennison

Received on Friday, 11 September 2009 20:43:14 UTC