Re: RDFa Lite and non-RDFa @rel values [Final Take?]

On Wed, Apr 25, 2012 at 9:28 AM, Gregg Kellogg <gregg@greggkellogg.net> wrote:
>>
>> Bottom line: I am still in favour of Stéphane's option 1. The only other alternative I can live with is to stay with the status quo and move on.
>
> I think Stéphane's option 1 is the way to go. Not doing this will result in much more bad behavior than leaving the status quo, IMO.
>

Here is, hopefully, my final take on all of this.  Thanks for bearing with me.


I went back through all of this and option 1 is stated as:

   Option #1: ignore @rel if it only includes HTML Link types as
defined at http://www.w3.org/TR/html5-author/links.html#linkTypes

and the original problem was:

<p vocab="http://schema.org/" typeof="Person">
   My name is <a href="http://example.com/" property="homepage"
rel="nofollow">Stéphane Corlosquet</a>.
</p>

generates, for text/html:

<> a schema:Person;
   schema:homepage "Stephane Corlosquet";
   schema:nofollow <http://example.com/>.

and generates for application/xhtml+xml:

<> a schema:Person;
   schema:homepage "Stephane Corlosquet";
   <http://www.w3.org/1999/xhtml#nofollow> <http://example.com/>.

There are really three problems that have been identified:

   1. The different interpretation of @property given the presence of @rel.

   2. Do values like "nofollow" and "alternate" generate triples in
HTML or XHTML documents?

   2. Different triples are generated depending on whether the
fragment is in an HTML or XHTML serialized document.

It is quite possible for the same document markup to be serialized via
HTML5 as either HTML syntax or XHTML syntax.  The referring
specification is still HTML5.  I think it would be really, really
unfortunate to continue generating different triples.  Personally, I
wish I had noticed that earlier but I didn't.

We need to parse out what option #1 really means in terms of the three
specifications HTML+RDFa 1.1, XHTML+RDFa 1.1, and RDFa Core 1.1 and
these three problems.

For problem 1:

Adjusting the interpretation of @rel values for HTML doesn't fix the
problem in general.  @property will be interpreted differently if you
use a CURIE.   The status quo is a "you lose, it is a quirk" situation
and having special cases for HTML/XHTML feels very unsatisfactory.
Especially given that we have no dynamic mechanism for loading a
profile for a host language.  That is, we're building in special case
process for specific media types that only "fixes" this form them
alone.

In retrospect, it was probably a mistake to use the presence of the
@rel/@rev attributes rather than their resolved values regardless of
the kind of document being processed.

Fixing this for HTML/XHTML without changing RDFa Core 1.1 requires
change HTML+RDFa 1.1. and/or XHTML+RDFa 1.1 to modify the definition
of "present" used in step 11 of section "7.5 Sequence" in the RDFa
Core 1.1 document.  It would only be available with these two media
types.  Note that we have the same problem if someone puts an empty
@rel attribute.

It would be much better to have the language adjusted in RDFa Core 1.1
to address the resolved value.  That's probably a substantive change
to that specification.


For problem 2:

I just had a long talk with Murray Maloney about the history of
@rel/@rev in HTML.  One gem that came from that conversation was that
it would have been much better to have used a CURIE or a URI.  I can
see that viewpoint and what we have today can be considered a
syntactic convenience.  Does that mean that they shouldn't generate a
triple?  @rel="license" is just as important as @rel="dc:rights"

I've said myself, that the set of actual values isn't well defined
beyond what is listed in the HTML5 (or previous) specification.  XHTML
1.1 had a different set but, looking forward, the only consistent set
is what is in HTML5.

If a @rel value can be ignored, there is a new feature being
introduced for terms.  Essentially, there is a set of term tokens that
can be ignored.  All places where terms are processed should have the
same interpretation.

If we go as far as excluding @rel="alternate", etc. in XHTML as well,
we'd have a problem in that other attributes like @property would have
inconsistent term processing unless we excluded them there as well.

So, terms that are ignored need to be ignored everywhere.


For problem 3:

Even though I have stated a preference for allowing and using HTML5's
rel values, I want even more a consistent world view between HTML and
XHTML syntaxes.  We should get the same triples for the same markup.
Choices about the terms being ignored in HTML syntax documents should
be the same for XHTML syntax documents.

We want these worlds to converge as much as possible.  This does mean
we might be breaking with the past in terms of RDFa and XHTML 1.1.
Since we have HTML5, I assert that all we will have is XHTML as HTML5
defines it.

All this means we would need to change both HTML+RDFa 1.1 and
XHTML+RDFa 1.1 in some way (or combine them) so that their initial
contexts and other processing rules are virtually the same.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Wednesday, 25 April 2012 18:24:56 UTC