This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7862 - Support Extended Processing Behavior via @profile/@version
Summary: Support Extended Processing Behavior via @profile/@version
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 blocker
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://html5.digitalbazaar.com/specs/...
Whiteboard:
Keywords: NE
Depends on:
Blocks:
 
Reported: 2009-10-09 20:30 UTC by Manu Sporny
Modified: 2010-10-04 13:56 UTC (History)
6 users (show)

See Also:


Attachments

Description Manu Sporny 2009-10-09 20:30:58 UTC
I am filing this bug at the request of the Chairs of the HTML WG, after rough group consensus was demonstrated, to address the @profile in HEAD issue in light of the new HTML5-EPB draft. There were no objections to attempt to address the issue on the telecon held on the October 8th, 2009 telecon.

The issue concerns the treatment of @profile in the current HTML5 Working Draft. The current WD obsoletes @profile, replacing it with rel="profile". This technically invalidates parser triggering behavior in technologies that are currently deployed, namely: eRDF, Microformats, GRDDL, DCHTML, and XHTML+RDFa.

A secondary concern is that @profile was obsoleted without specifying a reasonable replacement.

I have, along with the help of Julian, attempted to create a reasonable replacement for @profile (triggering extended processing behavior) while ensuring a clear transition path to the new mechanism:

http://html5.digitalbazaar.com/specs/html5-epb.html

I'm submitting this as a request to Ian to integrate these changes into the main HTML5 specification. Further details on the discussion related to addressing ISSUE-55 can be found on that bug tracker page:

http://www.w3.org/html/wg/tracker/issues/55
Comment 1 Maciej Stachowiak 2009-10-10 04:53:26 UTC
I think separate bugs should be filed for whatever is requested for @profile and @version. head@profile is a pre-existing feature from HTML4. html@version is not a pre-existing HTML feature. This bug report does not give any justification for @version, or explain how it relates to @profile.
Comment 2 Maciej Stachowiak 2009-10-10 04:55:07 UTC
Actually, the linked draft does three things:

- Defined a new html@version attribute.
- Defines a new <link rel="profile">rel value.
- Makes the legacy @profile attribute "obsolete but conforming" instead of "obsolete and noncomforming", without changing anything else about its status in the HTML5 spec.

It seems like all three of these suggestions should be separate bugs.
Comment 3 Ian 'Hixie' Hickson 2009-10-20 21:58:35 UTC
> - Defined a new html@version attribute.

I haven't added that, as it's no clear what problem it solves.


> - Defines a new <link rel="profile">rel value.

I haven't added that, as I don't understand the point (profile="" has clearly demonstrated that authors don't like or use profiles).


> - Makes the legacy @profile attribute "obsolete but conforming" instead of
> "obsolete and noncomforming", without changing anything else about its status
> in the HTML5 spec.

I haven't done this, as profile="" has been demonstrated to be pointless for authors, and therefore encouraging authors to use it is a bad idea.

If you disagree with these decisions, please escalate this to the issue tracker.
Comment 4 Julian Reschke 2009-10-20 22:03:08 UTC
s/decisions/opinions/.

Yes, I disagree with these. Mike, we should discuss on Thursday what exact tracker issues to open.
Comment 5 Maciej Stachowiak 2009-10-20 22:23:06 UTC
I think Manu has withdrawn the html@version proposal for now.

I think making head@profile more conforming is covered by ISSUE-55 (though I expect at least some would like it to be fully conforming, not just "conforming but obsolete" as Manu proposed): http://www.w3.org/html/wg/tracker/issues/55

For <link rel="profile"> we could use input on whether anyone wishes to pursue this further.
Comment 6 Manu Sporny 2009-10-21 03:20:33 UTC
(In reply to comment #5)
> I think Manu has withdrawn the html@version proposal for now.

Yes, although it causes problems for the XHTML+RDFa REC - I'll discuss this with the RDFa Task Force and see how they'd like to proceed.

> I think making head@profile more conforming is covered by ISSUE-55 (though I
> expect at least some would like it to be fully conforming, not just "conforming
> but obsolete" as Manu proposed): http://www.w3.org/html/wg/tracker/issues/55

I have heard that some want it to be fully conforming, but it didn't seem like those were the majority. The discussion seemed that a majority of those that didn't want @profile to be entirely obsolete were fine with it being obsolete but conforming.

> For <link rel="profile"> we could use input on whether anyone wishes to pursue
> this further.

I would expect the RDFa Task Force would want to pursue this route if @version and @profile in HEAD remained obsolete and non-conforming.
Comment 7 Michael[tm] Smith 2009-10-21 06:00:19 UTC
(In reply to comment #4)
> s/decisions/opinions/.
> 
> Yes, I disagree with these. Mike, we should discuss on Thursday what exact
> tracker issues to open.

Julian, OK, please ping me on IRC when you have time to chat

Comment 8 Julian Reschke 2009-10-21 06:12:02 UTC
(In reply to comment #6)
> > I think making head@profile more conforming is covered by ISSUE-55 (though I
> > expect at least some would like it to be fully conforming, not just "conforming
> > but obsolete" as Manu proposed): http://www.w3.org/html/wg/tracker/issues/55
> 
> I have heard that some want it to be fully conforming, but it didn't seem like
> those were the majority. The discussion seemed that a majority of those that
> didn't want @profile to be entirely obsolete were fine with it being obsolete
> but conforming.

The key here is that use of @profile, required by specs such as GRDDL and DC-HTML, should not cause a validator error *or* warning.
Comment 9 Michael[tm] Smith 2009-10-21 06:28:31 UTC
(In reply to comment #8)
> The key here is that use of @profile, required by specs such as GRDDL and
> DC-HTML, should not cause a validator error *or* warning.

Then it would seem that another possible solution is for them to work with validator maintainers to add specific validation support for GRDDL and DC-HTML to validators. Or I think a lot of people would argue that an perhaps better solution for them to consider amending or updating their specs to not include @profile at all.
Comment 10 Julian Reschke 2009-10-21 07:12:14 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > The key here is that use of @profile, required by specs such as GRDDL and
> > DC-HTML, should not cause a validator error *or* warning.
> 
> Then it would seem that another possible solution is for them to work with
> validator maintainers to add specific validation support for GRDDL and DC-HTML
> to validators. Or I think a lot of people would argue that an perhaps better

I don't think that solution scales. Is anybody who continues to use a now invalid element/attribute supposed to speak to *every* validator implementor?

Also, unless that's the default validation mode I really don't see how that would help with the issue.

> solution for them to consider amending or updating their specs to not include
> @profile at all.

Which sort-of requires us, as the HTML WG, to propose a replacement first. The "proposal" in HTML5 does not work (see separate bug).