This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6854 - if attribute values enumerated, allow case-sensitivity for meta content values
Summary: if attribute values enumerated, allow case-sensitivity for meta content values
Status: CLOSED INVALID
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 enhancement
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.w3.org/TR/html5/
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-29 06:49 UTC by Nick Levinson
Modified: 2010-10-04 13:57 UTC (History)
4 users (show)

See Also:


Attachments

Description Nick Levinson 2009-04-29 06:49:09 UTC
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
Comment 1 Toby Inkster 2009-05-19 15:54:50 UTC
This bug begs the question of whether case is a useful way of distinguishing between ambiguous subjects. I would argue that it is not.

The example given, even when treated case-sensitively is ambiguous. "Mercury" with a capital "M" could represent the planet, but could also represent the Roman god Mercury, or the band Mercury who happen to have released an album called "Mercury".

A better solution to this would be to provide a URL unambiguously identifying the topic of the document. Including RDFa in HTML5 would close this bug, as RDFa allows the following:

<head>
  <title>The Planet Mercury</title>
  <link xmlns:foaf="http://xmlns.com/foaf/0.1/"
        rel="foaf:topic"
        href="http://dbpedia.org/page/Mercury_(planet)" />
</head>

<head>
  <title>Mercury, my favourite element</title>
  <link xmlns:foaf="http://xmlns.com/foaf/0.1/"
        rel="foaf:topic"
        href="http://dbpedia.org/page/Mercury_(element)" />
</head>

<head>
  <title>Mercury, messenger of the gods</title>
  <link xmlns:foaf="http://xmlns.com/foaf/0.1/" 
        rel="foaf:topic"
        href="http://dbpedia.org/page/Mercury_(mythology)" />
</head>

<head>
  <title>Mercury, what a great band!</title>
  <link xmlns:foaf="http://xmlns.com/foaf/0.1/"
        rel="foaf:topic"
        href="http://dbtune.org/musicbrainz/resource/artist/89116de7-0aa7-47f5-a36c-c7f7cadd7013" />
</head>

<head>
  <title>Mercury, what a great album!</title>
  <link xmlns:foaf="http://xmlns.com/foaf/0.1/"
        rel="foaf:topic"
        href="http://dbtune.org/musicbrainz/resource/record/652217f0-35b0-4615-b955-4822d832cd0e" />
</head>
Comment 2 Nick Levinson 2009-06-08 03:30:27 UTC
All three would be even better.

URLs and page titles are a simple solution but aren't always practical for the purpose. That leaves a need for the internal solutions.

Where case suffices, allowing case-sensitivity would do the job by itself. Where case is not enough, your method above would do the job, as far as I can tell. The complexity of the latter, however, suggests also having the former, a meta attribute, as a simpler way out.

The page author can choose which if the three methods would fit a page.

Thanks.

-- 
Nick
Comment 3 Ian 'Hixie' Hickson 2009-06-28 10:48:13 UTC
This request is moot anyway, since as defined, the 'content' attribute isn't an HTML5 enumerated attribute, and so is always case-sensitive by definition.
Comment 4 Maciej Stachowiak 2010-03-14 14:48:07 UTC
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.