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

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 Wednesday, 7 April 2010 15:50:08 UTC