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

On Oct 10, 2009, at 11:19 AM, Manu Sporny wrote:

> Maciej Stachowiak wrote:
>>> 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.
>
> As you mention in a more recent e-mail, @version has been used in HTML
> 3.0, HTML 3.2, HTML 4.01 (loose), SVG 1.1, and SVGTiny 1.2. You didn't
> mention that it is also used in XHTML+RDFa 1.0 and was planning on  
> being
> used in XHTML2.

Neither XHTML+RDFa 1.0 or XHTML2 are precedents for HTML5. Both of  
those specs ignored compatibility with the HTML world.

> We also plan to use it in HTML+RDFa 1.0 and (X)HTML+RDFa
> 1.1. The only HTML-family languages it was not used in was HTML 4.01
> (strict), XHTML 1.0 and XHTML 1.1.

In the HTML (not XHTML) languages where it was allowed, it was either  
deprecated, or had a completely different syntax, or both.

>
> The idea was that we would define usage in the HTML5-EPB spec in  
> such a
> way as to not conflict with any of these previous languages, but in a
> way that helps specification writers make significant changes to  
> future
> specifications. More on this below...

Nonetheless, I think your version attribute is a new feature when it  
comes to HTML, not a legacy feature. The old version attribute was  
essentially a place to put the DTD string.

>
>> 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.
>
> Could you please clarify this statement? Specifically, how does
> re-defining @profile also not "step on the province of HTML itself"?
> Isn't everything we're doing in this WG in the province of HTML?

Well,  you haven't actually redefined @profile at all yet (other than  
making it conforming). If that happens, I may have an objection  
depending on the particular requirements.

>
>> 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
>
> I agree, so perhaps we could allow all of these values (note that
> @version is not a required attribute in the HTML5-EPB spec... it is a
> SHOULD, not a MUST):
>
> <html version="-//W3O//DTD W3 HTML 3.0//EN">
> <html version="-//W3C//DTD HTML 3.2 Final//EN">
> <html version="-//W3C//DTD HTML 4.01//EN">
> <html version="-//W3C//DTD HTML 4.01 Frameset//EN">
> <html version="XHTML+RDFa 1.0">
> <html version="HTML+RDFa 1.0">
> <html version="5.0">
> <html version="6.0">
> <svg version="1.1">
> <svg version="1.2">
>
> The algorithm for detecting these values is simple enough, so the
> problem isn't a technical one, is it?
>
> Keep in mind that we could just as easily rename @version to  
> @features:
>
> <html features="HTML 5+RDFa 1.0+SVGTiny 1.2">

That would be a slight improvement. At that point I'd ask: your draft  
makes all of head@profile, <link rel="profile"> and html@version (or  
html@features) conforming. In other words, it includes the legacy  
profile feature plus two different replacements. Why are all three  
needed? What different purposes do they serve? It seems like you could  
indicate the version of RDFa being used by a profile value just as  
easily as a version value. Why would an author specify both?

>
>> 4) This feature conflates versioning of the HTML language itself,  
>> with
>> versioning of extensions and metadata profiles. These are separate  
>> issues.
>
> Yes, but we can solve both problems with the same attribute. Are you
> arguing for @version AND @features? Or no @version and @features  
> instead?
>
>> 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 believe you mis-understand the purpose of the HTML5-EPB draft... the
> text is probably not clear and I'll try to clarify that in the
> statements below.
>
> I'm not "sneaking" versioning in or attempting to do anything  
> nefarious
> here. No more than Ian is trying to "sneak" features outlined in the
> HTML5 specification under the pretext of real world usage.
>
> What I am doing is attempting to address a technical issue. The
> technical issue is that we would like to change the behavior of RDFa  
> in
> version 1.1 in a way that is not backwards compatible, but in a way  
> that
> allows authors to specify that documents expect certain behaviors in  
> the
> user agents. @profile was a legacy mechanism used for this purpose,  
> but
> many don't use it for a number of reasons.

It seems like many don't use @version either, based on the study of  
RDFa content.

>
> The HTML5-EPB specification is about giving authors the power to  
> express
> Extended Processing Behavior in the documents that they are creating  
> in
> an easier way than using @profile.

Why is it necessary to include versioning of HTML itself in a  
mechanism intended for extended processing? We should not decide the  
versioning in HTML (whether it has any, and if so what the mechanism  
is) based on the needs of RDFa.

>
> This is important if we want to ensure backwards-compatability and  
> ease
> of authoring, while allowing ourselves to make deep, potentially
> conflicting changes to future specifications. I'll explain more in the
> response to Jonas that will follow this e-mail.

We don't want to allow ourselves to make deep, potentially conflicting  
changes to HTML5. This is exactly the reason HTML5 does not have a  
versioning mechanism. If there needs to be a versioning and  
disambiguation mechanism for extensions (such as profile), I can live  
with that. But you've also added a versioning mechanism for the core  
language. I consider that unacceptable.

Please read the past discussion on HTML versioning, including this  
thread, to understand the context of why this is controversial:
http://lists.w3.org/Archives/Public/public-html/2007Apr/0612.html

>
>> 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.
>
> Just changing @profile from non-conforming to conforming but obsolete
> doesn't actually address the real problem. We still want to get rid of
> @profile, but we need a solid replacement for it before we obsolete
> @profile.

Why did you include two different replacements (<link rel="profile">  
and <html version="">), a well as making the original feature  
conforming? Do we really need three different mechanisms for this?

>
> I'm trying to find some middle-ground with the HTML5-EPB spec...

You've actually stepped into even more controversial territory by  
stepping beyond a way to specify extended processing, into a mechanism  
to version the HTML language itself. I don't see how that is a middle  
ground.

I remain strongly opposed to your draft in its current form.

Regards,
Maciej

Received on Sunday, 11 October 2009 04:03:16 UTC