Re: PROPOSAL to close ISSUE-40: no triples for empty elements

On Sun, Sep 5, 2010 at 1:35 PM, Richard Cyganiak
<richard.cyganiak@deri.org> wrote:
> Sebastian,
>
> On 5 Sep 2010, at 18:07, Sebastian Heath wrote:
>>
>> Somebody may well want to represent that the value of data as it came to
>> them was "".
>
> Okay, let's suspend disbelief for a second and assume someone *really* wants
> to author a document with zero-length strings. They can still do it, using
> @content="".
>

And they can do it right now with '<span property="foo:bar"></span>'
as well. As I said when this issue came up before, if you don't want a
triple to be produced, don't put it in your RDFa.

>> I think we should not cut off the use
>> case whereby somebody is representing an empty string by <span
>> property="foo:bar"></span>.
>
> If you see this in a file in the wild, I *bet* you 100:1 that it's there
> because the RDFa is generated from a template that reads <span
> property="foo:bar">{$templatevar}</span> and the template author didn't
> consider the effect of a zero-length template var on the generated RDFa (or
> couldn't be bothered to add the extra template code to suppress the
> zero-length triple).
>

Bet? Why not just leave the spec as is and then it doesn't matter what
either of us is is willing or unwilling to wager.

But I'll bet just as much that the value in $templatevar  is "" and
that's what the developer wanted to show. Again, they can do that
right now so why break what isn't fixed. Keep backwards compatibility.

 Or that the data is natively RDFa and, again, that's what the author
wants to show.

>> If there's an @property, then it's probably RDFa and should
>> be parsed. Simpler for authors, simpler for parser writers.
>
> It is definitely *not* simpler for authors. It means that templates which
> generated completely valid XHTML before adding RDFa now need special casing
> once RDFa is added, because otherwise they will generate empty RDFa literals
> which do not match author intent.
>

We may have a terminology issue. Authors, developers, consumers. By
"authors" I mean those of us modeling data. Most of my RDFa isn't
produced by templates but is the native format of the data I'm using.
It is much easier for me to leave the spec as is. '<span
property="foo:bar"></span>' is simple and unambiguous, doesn't require
knowing about a special case in the spec. I could just repeat "it's
simpler for authors" but that might seem rude. So again, the handling
of "text empty" elements isn't broken, is meaningful, and is useful so
why change it?

> It is also *not* simpler for consumers of RDFa data, because it requires
> special casing in downstream apps if they want to deal with real-world data
> from the wild.
>

I don't get this.

If there's an empty string as the object of a triple, I'll assume
that's what the author intended. I think it would be strange to do
otherwise. When I am consuming RDFa downstream, my only choice is to
trust the upstream. Especially when I'm doing something like looking
for empty strings.

 Real world case for me: I work with data that is "born RDFa" in
xhtml-encoded textbases. I can't use a parser to find those triples
with "" as the object if I have to have marked them with 'content=""'.
That's a catch-22 that doesn't exist right now. Why create it?

> It certainly *is* simpler for the spec writers and for parser implementers,
> but that should be a minor concern. Document authors before library users
> before library implementers before spec writers!

I'm an author. It's easier for to me leave the spec as is. But I worry
that we've very quickly approached the "at loggerheads" stage and I
apologize for that.

>
> Best,
> Richard
>
>
>>
>> -Sebastian

Received on Monday, 6 September 2010 00:08:02 UTC