This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In Editor's draft as of 2009-06-07: "User agents should ignore the profile content attribute on head elements. When the attribute would be used as a globally unique name, the user agent should instead always assume that all known profiles apply to all pages, and should therefore apply the conventions of all known metadata profiles to the document." That ignores the fact that one use for specifying profiles is disambiguation. If a term with the same name is defined in multiple profiles, and the recipient "knows" them, it can't decide which definition to use in absence of advice from @profile. I agree that disambiguation is one of the weakest points of @profile, but it is there, and the suggested replacement does not have it.
Could you give an example of some software that supports profiles with overlapping terms and that uses the profile attribute for disambiguation?
The purpose is disambiguation. If several profiles use overlapping syntax (be it meta names, or a specific notation in meta names), then the profile attribute allows the recipient to understand which interpretation is correct. The fact that I currently do not have an example for a case like that doesn't affect the correctness of the argument.
The only reason this is in the spec at all is because there is software that depends on it. We're not including definitions of obsolete features based on theoretical concerns, that would be a waste of our time _and_ a waste of the time of the people who might end up using those definitions to be compatible with legacy content or software (since, as far as I can tell, there is no such content or software).
I guess this will need to be escalated to an issue then. Mike, as you're reading this, are you ok with that?
(In reply to comment #4) > I guess this will need to be escalated to an issue then. Mike, as you're > reading this, are you ok with that? How is this different from issue 55? (head/@profile missing, but used in other specifications/formats) Isn't the gist of this bug that the suggested replacement for the profile attribute is not adequate and that therefore the profile attribute is still needed?
(In reply to comment #5) > (In reply to comment #4) > > I guess this will need to be escalated to an issue then. Mike, as you're > > reading this, are you ok with that? > > How is this different from issue 55? (head/@profile missing, but used in other > specifications/formats) > > Isn't the gist of this bug that the suggested replacement for the profile > attribute is not adequate and that therefore the profile attribute is still > needed? Almost. If the author comes up with a way suggested replacement that does work, this would close this bug, but not the issue in the tracker (which is more about support for existing content).
escalated to tracker http://www.w3.org/html/wg/tracker/issues/82
The UA conformance requirements for @profile have changed. Do the new ones still have this problem? ------------ User agents should ignore the profile content attribute on head elements. When the attribute would be used as a list of URLs identifying metadata profiles, the user agent should instead always assume that all known profiles apply to all pages, and should therefore apply the conventions of all known metadata profiles to the document, ignoring the value of the attribute. When the attribute's value would be handled as a list of URLs to be dereferenced, the user agent must use the following steps: Split on spaces the value of the profile attribute. Resolve each resulting token relative to the head element. For each token that is successfully resolved, fetch the resulting absolute URL and apply the appropriate processing.
No. Profile names can be used to disambiguate. If two extensions use overlapping syntax (or meta names), the presence of the extension's profile URI allows the recipient to decide which extension was used, and how to interpret the document. The proposed text does not address this use case. There's another problem in the text in that it suggests different behavior based on the type of the URLs without telling how to distinguish those (hint: it's not possible), so I would prefer if the spec just stated what the attribute's contents is, and would stay silent otherwise.
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.