Re: @rel syntax in RDFa (relevant to ISSUE-60 discussion), was: Using XMLNS in link/@rel

On 01/03/2009, at 10:33 AM, Ben Adida wrote:

>
> Mark Nottingham wrote:
>> Are people using RDFa in HTML using the profile mechanism, or  
>> xmlns, or
>> both? Do they flag the use of RDFa in any way (like @version does for
>> XHTML+RDFa)?
>
> We recommend using the doctype with @version. We've determined that,
> while @profile is the right approach for interpreting new values of
> @rel, it doesn't cover new attributes, so it's not the right way to  
> flag
> RDFa.

Sorry, I should have been more clear; I'm talking about in HTML4  
(since CC doesn't require or recommend XHTML for CC+).


> That said, as Sam brought up, we know that we live in a world of web
> widgets, and so we expected that RDFa might well get deployed  
> without a
> flag... which is why we structured RDFa to be as backwards- 
> compatible as
> possible. New attributes, clear separation of syntax for prefixed  
> values
> of @rel, etc... Not perfect, but the best we could come up with to  
> stay
> sane in a world where HTML fragments are flying around.

What's wrong with a URI (i.e., an actual, syntactic one, instead of a  
shorthand)?


> And of course, there's *one* RDFa syntax, independent of the
> vocabularies used. I mention this to contrast with microformats,  
> which,
> while very useful, introduce new values of @rel and globally  
> meaningful
> values of @class typically without ever using any kind of flag. And no
> one seems to be worried about that, even though it's vocabulary- 
> specific
> and the syntax changes from one vocab to the next :)

I'm concerned, but there are always going to be things working outside  
the bounds of the standards. I just want to minimise that happening  
inside standards, because then we (collectively) are giving people  
conflicting advice.


>> What I can see doing is adding information in the appendices  
>> (alongside
>> that for HTML4 and Atom) about relations in XHTML (after their  
>> syntax is
>> clarified, see other parts of this thread) and XHTML+RDFa; that seems
>> pretty straightforward.
>
> In Appendix A (HTML4), you say:
>
> =======
> For example, in HTML:
>
>
>   <html>
>     <head profile="http://example.com/profile1/">
>       <link rel="foo" href="/bar">
>     </head>
>     [...]
>
>
> could be represented as a header like this;
>
>   Link: </bar>; rel="http://example.com/profile1/foo"
> ========
>
> This might be read to imply that @profile can only be used to prefix a
> @rel value. I don't think that's right, given the HTML4 definition [1]
> which, I believe, allows a profile to do just about anything to
> interpret a @rel value.

Yes, that's true. At best, this could be *one* (fairly obvious,  
although not without problems) way of doing it.


>> if we could come to one way of doing this per syntax, and ideally one
>> way of doing this across the HTML family of languages (although  
>> that may
>> be asking too much).
>
> I would like that, too. We're listening to the feedback from the HTML5
> WG to see if we can find a common mechanism for RDFa in all versions  
> of
> HTML which include RDFa.

True, but AIUI that's a moving target. For the moment, my focus is on  
HTML4.


>> As it sits, a generic parser can't reliably identify the link  
>> relations
>> in an HTML4 document just by looking at it; if I understand what's  
>> being
>> done here, the relation "ab:foo" might mean radically different  
>> things
>> in two different documents, even if they have the same profile
>> attribute, thanks to the use of xmlns. This is bad.
>
> The relation is the fully expanded URI, so I'm guessing you mean the
> string value of the @rel attribute before it gets processed.
>
> This situation is, I believe, already the case in HTML4 given that
> @profile affects the interpretation of the @rel value. Unless I'm
> missing something, I don't see how XHTML1.1+RDFa is much different  
> here.
> More or less, RDFa's prefix-based processing of @rel is a default
> profile for XHTML1.1+RDFa.

If I have two HTML4 documents in front of me, and they both have the  
profile "http://example.com/foo" and a link with the relation "bar", I  
think I should be able to assume that those links have the same  
relation. I may not be able to resolve their semantics, or  
disambiguate them from other relations, but I think the spec gives me  
that.

Using RDFa in HTML4 breaks that assumption. Now, this *may* be a  
necessary evil (see below), but if that's the case, it should be  
widely agreed-upon, and ideally, this circumstance should be easily  
identifiable to a generic parser.


>> 1) Can CC require (or at least recommend) the use of @profile, and
>> mandate that the cc: prefix always be used? This would help  
>> disambiguate
>> these relations in a way that's more compatible with generic parsing.
>
> As I mentioned above, we don't believe @profile is the right way to go
> because RDFa also includes new attributes. We do recommend that folks
> write valid HTML, and to write valid RDFa, you have to use the
> XHTML1.1+RDFa doctype and HTML @version. That is enough, I believe, to
> trigger the appropriate interpretation of @rel values.

Sorry, I was talking about in HTML4. If you requires XHTML+RDFa  
unambiguously for CC+, this issue goes away in theory, although I  
suspect people will still unthinkingly transplant the syntax into  
HTML4. Therefore, you really do need to say *something* about HTML4  
(as well as bare XHTML, for that matter), and provide a way to make it  
unambiguous.

As I said before, 99% of the people reading that document will assume  
HTML4, and I think it's also a safe wager to say that something  
approaching that number have never heard of RDFa. Do you believe  
otherwise?


> I'm conflicted about recommending the consistent use of the cc:  
> prefix.
> On the one hand, we basically already do this in all of our examples,
> and of course I'd prefer to make life easier for you. On the other  
> hand,
> I don't want to give the impression that parsers should be lazy about
> de-referencing the prefixes.

But an HTML4 parser has absolutely no business knowing about xmlns,  
period.


> Do you see my point about how @profile already negates the goal of  
> doing
> raw string comparison on @rel values?

To a degree, yes, but see above.


>> 2) The Link draft can add a note that XHTML+RDFa-style syntax might
>> appear in HTML4; implementations can either consider them locally- 
>> scoped
>> extension relations (i.e., not meaningful in a global scope), or  
>> try to
>> parse them if they like.
>
> I think that would be helpful, yes.
>
>> 3) If relations are going to be used more frequently in HTML4, some
>> guidelines of best practice would be really helpful. The Link draft
>> suggests a way to get from @profile + @rel in the HTML4 appendix;  
>> review
>> of that would be appreciated, as I'm beginning to suspect it may need
>> revisiting.
>
> That's what I was commenting on above: I'm not sure you can assume  
> that
> @rel is simply appended to @profile.

Agreed.

At this point, I think the most helpful thing that could be done for  
HTML4 (and I'm really only talking about it, at the moment) is to come  
up with some helpful, global (i.e., not RDFa-specific) conventions for  
reuse.

E.g., a profile URI whose semantics is "all link relations in this  
document that have a colon in them are (syntactic) URIs." That would  
be less ambiguous than what the Link appendix proposes now, and also  
opt-in.

I suppose if you really wanted to keep the prefix syntax, we could  
have another profile URI whose semantics were, roughly, "all link  
relations in this document that have a colon in them have a prefix  
defined in a HTML <meta> element, where the prefix is defined by the  
title attribute." Just a rough idea; IMO that's much more HTML4- 
friendly then either using xmlns or using a new attribute like profile.

The more I look at it, the more I like the first profile; I'm likely  
to write that into the next draft of Link, in some form. However, we  
need to have a long, hard think about the ramifications of this second  
profile. Again, what's wrong with a bare URI? If the answer is just  
"saving bytes" it's a very poor excuse indeed.

In any case, if we go in this direction there will also be people who  
don't bother to declare the profile, but that's OK; that just means  
that the relations in those documents won't be globally unambiguous,  
and anyone who makes assumptions about their meaning does so at their  
own risk.

AFAIK the alternative to this approach is to throw up our hands and  
admit that link relations in HTML4 are a lost cause, and anyone who  
uses them suffers from some semantic fuzziness.

Thoughts?

--
Mark Nottingham     http://www.mnot.net/

Received on Sunday, 1 March 2009 00:28:02 UTC