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/
