Re: ISSUE-55: Re-enable @profile in HTML5 (draft 1)

Mark Birbeck wrote:
> In section 1.1, you say that @profile is a "means to specify the
> location of one or more meta data profiles", but since there is no
> requirement for the document to be retrieved, then there is no way to
> mandate that the document actually exists -- and indeed, that's part
> of the usefulness of @profile.

Yes, you're right.

Noted:

http://rdfa.info/wiki/html5-extended-processing-behavior-issues#Issues

> On section 2.1: there is already a W3C version string format, and I
> don't think we should invent another one. Specifically, the '+' has a
> special meaning in feature strings, so I don't think you should use it
> as a separator. You don't actually need the '+' as a separator anyway,
> since the names of the interfaces always begin with a letter, and the
> version numbers always begin with a number.

Do you have a link to where the version string format is specified? The
format was meant to be backwards-compatible with XHTML+RDFa while being
as flexible as possible. I agree that we should re-use what's already
specified.

Noted:

http://rdfa.info/wiki/html5-extended-processing-behavior-issues#Issues

> (You have them both as NCNames, but since all of your versions are
> numbers, then I assume that's a typo.)

Sadly no, it's not a typo. I started by being as loose as possible...
depending on the community to tighten the format down. I thought that
maybe people would want to do something like this:

version="HTML+MathML 3.0draft"

That might be overkill, though.

> This might also allow authors to use the more flexible alternative:
> 
>   @version="RDFa 1.0"
> i.e., without either "HTML" or "XHTML".

What would specifying that mean in an HTML or XHTML document? What about
in an SVG document? How would it be used?

> In section 2.2, I think it's incorrect to have @rel="profile" since by
> the time this value is parsed, it will be too late in the sequence. In
> other words, @rel="profile" it is not equivalent to @profile, since
> the latter can be read before parsing begins, whilst the former is
> read as part of normal processing.
> 
> (It's like putting the MIME type or character encoding into the
> document; they are metadata about the transmission envelope, so by the
> time the document has been transmitted, it's too late to act on the
> values.)

Noted:

http://rdfa.info/wiki/html5-extended-processing-behavior-issues#Issues

Part of me agrees with you. We do, however, have precedent for in-band
processing information for the document via the BASE element. For
example, in RDFa - we require that the @href value for <base> in <head>
is extracted before triples are generated. We do this because that value
determines how you resolve relative URLs for triples.

However, that doesn't mean that we should follow that example. Yours is
a perfectly legitimate argument to not obsolete the profile attribute.

Personally, I don't like the @profile attribute (even I often forget to
use it when marking up Microformats). I think it's been proven that it's
not widely useful, and to support Microformats, GRDDL (and other such
technologies), all we need is rel="profile".

The only burden this places on UAs is that they have to parse <HEAD>
completely before running any sort of extended processing behavior on
the document. Since we already must do this for RDFa, I don't see it as
an additional requirement. However, I may be missing something.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The Pirate Bay and Building an Equitable Culture
http://blog.digitalbazaar.com/2009/08/30/equitable-culture/

Received on Monday, 28 September 2009 13:33:58 UTC