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

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. 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.

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...

> 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?

> 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">

> 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.

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.

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.

> 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.

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

-- 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 Saturday, 10 October 2009 18:20:13 UTC