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


I have comments embedded below:

Jeni Tennison wrote:
> On 11 Sep 2009, at 16:36, Shane McCarron wrote:
>> 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):
>>      <span about="#shane" property="foaf:name" datatype="">Shane</span>
>>      <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.
> .....
> The next possibility is that it's a plain literal, if it meets any of 
> the conditions:
>        @content is present;
>      or all children of the [current element] are text nodes;
>      or there are no child nodes (in which case the literal value is 
> the empty string);
>      or the body of the [current element] does have non-text child 
> nodes but @datatype is present, with an empty value.
> In this case, all children of the current element are text nodes, so 
> the object is a plain literal and the triple should be:
>   <#shane> foaf:name "Shane" .
I agree.
> 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". 

> 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
> 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:
>   <> <> <> .
> 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.
> For @about, @resource, @href and @src, the wording is "by using the 
> URI from @{attribute}, if present, obtained according to the section 
> on CURIE and URI Processing;". I think the "if present" here refers to 
> "the URI from @{attribute}" rather than just "@{attribute}", such that 
> if @about does not resolve to a URI there is no value present and it 
> is as if the entire attribute had not been there. So:
>   <p xmlns:ex="" about="">
>     <span about="[bogus:bogus]" property="ex:prop">Test</span>
>   </p>
> results in the triple:
>   <> <> "Test" .
I agree with your interpretation, and with the result you show above.
> 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 know what the spec says, and I respect your opinion about how you are 
interpreting it.  Where we are differing in our interpretation is with 
regard to @property.  The language surrounding @property has been 
confusing to many, including me.  I spend AGES discussing this with Mark 
and Manu and others during the development of the spec and of my example 
implementation.  I am reasonably confident that my interpretation is 
consistent with what we meant when we wrote the spec.

It really comes down to "the principle of least surprise".   If  I 
supply erroneous data, that data should be ignored (at least with 
respect to the default graph).  If data is ignored, then there should 
not be unexpected side-effects from ignoring that data.  Creating a 
bnode because @property="" was defined would be such an unexpected 
side-effect in my mind.

I would be interested in hearing Mark's opinion, but it's late in 
England and if he has any sense he is off with his bride and family for 
the weekend.

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

Received on Friday, 11 September 2009 19:41:53 UTC