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

On Sep 27, 2009, at 5:03 PM, Manu Sporny wrote:

> I volunteered for an action to produce a draft document that included
> @profile in HTML5:
>
> http://www.w3.org/html/wg/tracker/actions/144
>
> The document attempts to address the long standing ISSUE-55:
>
> http://www.w3.org/html/wg/tracker/issues/55
>
> After speaking with Julian over the weekend, we explored the  
> possibility
> that perhaps the document should focus on the concept of extending
> processing behavior for user agents via @profile and @version. Perhaps
> even stating that we'd like to move away from @profile (because it
> hasn't been used as much as we'd like), toward something that is  
> simpler
> and has been used in both XHTML and RDFa: a specifically formatted
> @version attribute.


[...snip...]

> This is a very rough conceptual draft and thus we could end up  
> adopting
> all of it or none of it. It attempts to find a delicate balance  
> between
> the advice given via the HTML WG, WHAT WG, and RDFa TF:
>
> http://html5.digitalbazaar.com/specs/html5-epb.html

I'm strongly against including @version in this draft, to the point  
that I would likely oppose FPWD in its current form. I say this for  
the following reasons:

1) head@profile is a feature inherited from HTML4, and external  
standards relied on it in good faith. But html@version has never been  
been in any version of HTML, so no one has had any valid reason to  
depend on it.

2) Defining the version attribute in this extension spec steps on the  
province of HTML itself, if it ever wants to include a versioning  
mechanism for the base language.

3) If we wanted versioning in HTML itself, I think it would be much  
better to align with SVG's version attribute. SVG just has a version  
attribute with a version number. So if HTML6 makes some incompatible  
changes, we'd like to be able to say <html version="6.0">, just as you

4) This feature conflates versioning of the HTML language itself, with  
versioning of extensions and metadata profiles. These are separate  
issues.

5) People may think that it makes sense to allow legacy use and  
processing of @profile, but not agree that HTML should have a  
versioning mechanism. By putting these in one spec, we're forced to  
decide on two completely separate issues at once as a Working Group,  
and anyone deciding on which specs are applicable specifications (e.g.  
for purposes of making a validator) is also forced to decide. I'm  
against sneaking in versioning under the pretext of restoring support  
for a legacy feature.


I also think what this draft specifies for head@profile does not add  
anything to what HTML5 already specifies, other than making it  
"obsolete and conforming" instead of "obsolete and nonconforming". You  
don't specify what values are conforming or what the processing  
requirements are. The definition of the link type should be separate  
from that.

Regards,
Maciej

Received on Saturday, 10 October 2009 04:31:57 UTC