Re: Change Proposal for ISSUE-82 (Profile-Disambiguation), was: ISSUE-82 - profile-disambiguation - Chairs Solicit Proposals

On Wed, Apr 7, 2010 at 8:49 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> SUMMARY
>
> Subsection 11.3.4 ("Other elements, attributes and APIs") of section 11.3
> ("Requirements for implementations") talks about implementation requirements
> for the head/@profile attribute.
>
> This in itself is a bit strange, as there actually is no *required* behavior
> for head/@profile - it is an annotation, and its use is totally optional.
>
> That being said, the actual text is both misleading and inaccurate. This
> proposal attempts to fix this description; a broader change would be to
> actually document head/@profile properly as conforming attribute.
>
> RATIONALE
>
> Stated "implementation requirements" should actually describe the main use
> case of head/@profile (which is disambiguation); they currently do not.
>
> DETAILS
>
> The current text (as of 2010-04-07) reads:
>
> "...User agents should ignore the profile content attribute on head
> elements."
>
> Comment: if they "should" ignore it then there is no implementation
> requirement, right?
>
> "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."
>
> Comment 1: The condition "When the attribute would be used as a list of URLs
> identifying metadata profiles" first of all is untestable, second of all
> it's always true according to HTML4.
>
> Comment 2: "...the user agent should instead always assume that all known
> profiles apply to all pages..." -- this neglects the case where the
> attribute value is actually needed to disambiguate to extensions that use
> the same syntactical extension point.
>
> "When the attribute's value would be handled as a list of URLs to be
> dereferenced, the user agent must use the following steps:"
>
> Comment: Untestable.
>
> The proposed new text addresses the main issue being that profile URIs may
> be needed for disambiguation, thus, *in general*, can't be simply ignored.
>
> Proposed new text:
>
> -- snip --
> [Supplemental]
> interface HTMLHeadElement {
>           attribute DOMString profile;
> };
>
> The profile attribute contains a set of white-space separated meta data
> profile names in the form of URLs.
>
> Processing of meta data profiles is optional.
>
> Meta data profile names can both be globally unique names, or links to
> further information to be dereferenced.
>
> In the first case, the mere presence of a profile name can be used to enable
> profile-specific extensions. This can be important in case the user agent
> supports multiple extensions that can not be disambiguated without this
> additional annotation.
>
> In the second case, the profile name can be resolved relative to the head
> element, resulting in an absolute URL that can be fetched for appropriate
> processing.
>
> The profile IDL attribute of the head element must reflect the content
> attribute of the same name, as if the attribute's value was just a string.
> (In other words, the value is not resolved in any way on getting.)
> -- snip --
>
> IMPACT
>
> 1. Positive Effects
>
> The misleading statement about "should ignore" is removed; the actual use
> case is explained.
>
> 2. Negative Effects
>
> Stating the actual use case may cause people to question why the profile
> attribute is considered obsolete in the first place.
>
> 3. Conformance Classes Changes
>
> None.
>
> 4. Risks
>
> None.
>
> REFERENCES
>
> None.

Why not simply remove any and all mention of @profile from the HTML5
specification? This way the separate @profile spec that is being
developed (right?) has the freedom to define anything it wants. This
would put @profile on par with RDFa and Microdata.

/ Jonas

Received on Wednesday, 7 April 2010 16:03:43 UTC