[Bug 6854] New: if attribute values enumerated, allow case-sensitivity for meta content values

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6854

           Summary: if attribute values enumerated, allow case-sensitivity
                    for meta content values
           Product: HTML WG
           Version: unspecified
          Platform: All
               URL: http://www.w3.org/TR/html5/
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P3
         Component: HTML 5: The Markup Language
        AssignedTo: mike@w3.org
        ReportedBy: Nick_Levinson@yahoo.com
         QAContact: public-html-bugzilla@w3.org
                CC: public-html@w3.org


The present draft requires that attribute values if enumerated be
case-insensitive (section 2.4.3). I propose an exception that is narrow and, I
believe, won't be a problem for most user agents and conformance checkers.

Elsewhere, I'm proposing that page authors be able to classify pages by subject
using standard classification schemes. Because many good classification schema
exist, it's not feasible to ensure that case will never matter. This
information would be used, if at all, by search engines and directory editors;
thus, most UAs should be unaffected by case in such a value. In other words, if
a UA noncompliantly imposed case-insensitivity and still presented the Web page
as the author intended, no viewer's experience would be hampered by that
particular noncompliance. Those few users who want their UAs to handle case
properly in this context, i.e., to be case-sensitive, would likely be directory
editors or search engine managers, for whom custom-built robots would be fine.

The exception, therefore, should be in meta elements that include, along with
any other keyword-value pairs, the keyword-value pair case-sensitivity="true".
The case-sensitivity keyword would be valid only for the meta element
containing it; it would have to be repeated by a page author for every meta
element to which it is to apply. A value of false or any other value would be
the same as the absence of that keyword. Example: If a hypothetical Smith
Cataloging System, represented here by the hypothetical keyword name
subjectsmithsystem, has classifications for both liquid metals and planets
which in the original catalog differ only in case: <meta
name="subjectsmithsystem" content="Mercury" case-sensitivity="true" /> would
mean the planet, because the search engine robot would see that
case-sensitivity is true and so extract "Mercury" and not "mercury". The search
engine or directory would then classify the page with planet-relevant pages and
not with metal-relevant ones.

These keywords do use enumerated values, although the enumeration is to be
found in the catalogue referenced by the keyword proposed in the MetaExtensions
Wiki and may be composed of many thousands of possible values. If such values
are considered non-enumerated, none of this matters because case can be
required, as when values are personal names. However, if a value supplied can
be validated by a recipient by checking it against a finite list authorized
under HTML5 then I think that counts as enumerated.

Therefore, I propose that section 2.4.3 (in W3C Working Draft (23 April 2009))
be edited to add the following to the end of the existing 2d paragraph:

Exception: For a meta element containing the keyword-value pair
case-sensitive="true" and a name-content pair, the content value must be an
ASCII case-sensitive match for one of the given keywords that are not said to
be non-conforming, with no leading or trailing whitespace.

Set "name" and "content" in red each time.

This implicitly references section 4.2.5, and therefore the latter section
should also be edited by adding the following as a paragraph to the end of the
section (before section 4.2.5.1):

For a name, the value may be case-sensitive only if in the same element the
keyword-value pair case-sensitivity="true" is present, as authorized by section
2.4.3.

Set "name" in red.

Thank you.

-- 
Nick


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 29 April 2009 06:49:27 UTC