Re: Comment on RDFa 1.1 Core: Empty elements should not create literals

Yes, @content overrides and yes whitespace can be tricky. But the
semantics and results of

   '<span property="ex:facet1"></span>'

 seem unambiguous and I'm not sure it's useful to say specially that
this shouldn't generate a triple.

And if:

<span property="ex:facet1">
</span>

appears, then maybe the author wants an XMLLiteral with value of line
return as its represented in the text. Should we really say this is
flat-out wrong and should be ignored? We  should allow this form and,
again, not special case. Especially since it's easy to not have that
triple be generated by not representing it in the RDFa.

 -S.


On Thu, Aug 5, 2010 at 4:47 PM, Mark Birbeck
<mark.birbeck@webbackplane.com> wrote:
> Hi Sebastian,
>
>> Empty values can be useful so I'd prefer to stick to the current behavior.
>>
>> If the resource being described doesn't have a particular property, it
>> shouldn't be specified. That's different from saying a property has a
>> value of the empty string.
>>
>>  Obviously, I'm not saying anything new here. Just hoping to retain
>> flexibility in the syntax and processing model.
>
> That's true. But a few months ago on a different issue, Toby drew
> attention to the fact that whitespace rules for elements are different
> to those for attributes. This is related because it makes me wonder
> whether you can guarantee to consistently get an empty string when
> using empty elements.
>
> I'd be interested to hear what Toby thinks on this, but it would seem
> that if you really *must* have an empty string then you should do
> this:
>
>  <span property="p1" content=""></span>
>
> That will then cope with any of the following:
>
>  <span property="p1" content="">
>  </span>
>
>  <pre property="p1" content="">
>  </pre>
>
>  <span property="p1" content=""><!--
>    nothing to see here
>  --></span>
>
>  <span property="p1" content=""><[CDATA[
>  ]]></span>
>
> and so on.
>
> None of which is to say I'm for or against Richard's proposal; I'm
> just saying that your use-case might have a different solution anyway,
> which is unrelated to Richard's proposal.
>
> Regards,
>
> Mark
>
> --
> Mark Birbeck, webBackplane
>
> mark.birbeck@webBackplane.com
>
> http://webBackplane.com/mark-birbeck
>
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
>

Received on Thursday, 5 August 2010 14:25:38 UTC