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

Recorded:
http://dev.w3.org/html5/status/issue-status.html#ISSUE-082

Regards,
Maciej

On Apr 7, 2010, at 8:49 AM, Julian Reschke wrote:

> On 24.02.2010 14:00, Sam Ruby wrote:
>> ...
>> If you don't think it is a good use of our time, the alternative is  
>> to
>> simply close the issue without prejudice. If we get to the point  
>> where
>> somebody actually puts together a coherent and actionable proposal,  
>> we
>> can discuss it at that time.
>>
>>> Best regards, Julian
>>
>> - Sam Ruby
>> ...
>
> Here's a Change Proposal for this issue. I apologize for the delay.  
> Also, it's a bit strange to force a proper description of @profile  
> into an "implementation requirements" section, as @profile is  
> totally advisory, and to ignore it is totally ok. But the current  
> spec says "should ignore", and that's why we're debating this.
>
> With this explanation, on to the change proposal:
>
> 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.
>
> Best regards, Julian
>

Received on Friday, 16 April 2010 08:27:48 UTC