<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ben Adida wrote:
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap="">Shannon wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">
<link rel="vocabulary"
href=<a class="moz-txt-link-rfc2396E" href="http://some.official.vocabulary/1.1/metadata.cm">"http://some.official.vocabulary/1.1/metadata.cm"</a>>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Not workable, as this in the HEAD of the document and oftentimes we
simply can't expect users to be able to modify the head of the document
(widgets, blog engines where you can only modify the content of a blog
entry, etc...)
  </pre>
</blockquote>
<br>
I thought I made this clear. There are at least 4 methods or applying
CSS. Each has a purpose. Use the one the works for your situation. Two
of these methods do not require a seperate document or code in
<head>. Discussing the shortfalls of the others for your
particular use is pointless.<br>
<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap=""><!---->
I don't think what you wrote above is widely used or understood. In
fact, I think it's not used at all, whereas RDFa is actually being used
today.
  </pre>
</blockquote>
I'm referring of course to the behaviour and syntax, not the elements
or properties, assuming that behaviour were basically the same as CSS.<br>
<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap="">
Also, one big hole: how do you make a statement about another item? How
do you describe multiple items on a page? How do you relate two items on
a page? Say, the Craigslist example, with multiple listings?
  </pre>
</blockquote>
<br>
The same way RDFa does except it's done within a metadata block or
attribute.<br>
<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap="">
eRDF tried to squeeze everything into @class, and it isn't able to be as
flexible as RDFa (and thus as we need) in this respect. It has a lot of
trouble expressing data about multiple items.
  </pre>
</blockquote>
eRDF is a hack that abuses the purpose of @class. Class was never meant
to carry meaning beyond group membership.<br>
<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap="">
What's surprising to me is this attempt to shoe-horn so much unexpected
stuff into @class. What is so sacred about HTML4 that *this* issue can't
be helped by a bit of rethinking? Certainly, everything else seems to be
up for rethinking in HTML5.

  </pre>
</blockquote>
Class is not being shoehorned in this proposal. Nothing is being put
into class except class names.<br>
<br>
I'm not sure I'd call RDFa "rethinking". It seems a lot like all the
other attributes stuffed into HTML over the years. When the rethinking
on HTML attributes came it was realised that many of those attributes
were underused, inflexible or just better off somewhere else. CSS was
the rethinking of @width, @background, @color etc and a host of
non-style attributes have been removed from HTML5. You're already
asking for at least 4 new attributes and while you've made a case for
why they could be desirable inline you haven't made a case for why they
*have* to be inline or why they *have* to be attributes. This proposal
provides the author the choice of inline, inline blocks, or external
files. Each is useful for differing circumstances.<br>
<br>
Your proposal requests 4 or 5 new attributes. This proposal should
support any number of current or future RDF metadata attributes without
changing HTML. Future metadata formats and extensions can be developed
in a metadata working group without being depended on HTML support.<br>
<br>
Your proposal depends on RDF. This proposal is mostly format neutral.
New metadata types can be supported in the future using
type="metadata/type" on link and metadata elements.<br>
<br>
I think you see the problem to be solved as "RDF-in-HTML". I would
prefer the problem defined as "Metadata-in-HTML".<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap="">
By the way, we considered using @class instead of @typeof, but
we met with serious opposition from folks who didn't want us to mess
with the existing uses of @class.

  </pre>
</blockquote>
I haven't seen these discussions but were these objections because the
opponents did not understand the concept of multiple classes; or were
they because you were trying to use URIs or namespace seperators
directly in class names eg, class="dc-title"? What precisely were the
objections based on? Was the discussion about a seperate metadata
definition like we are talking about here or was the proposal actually
trying to cram all your RDF namespace, about and typeof data directly
into the class attribute (like eRDF)?<br>
<br>
>From what you've said here and elsewhere it really sounds like you were
really discussing adding meaning to the value of @class. This is not
what this proposal is about and it isn't what class is for either. For
example this is consider bad:<br>
<br>
<div class="red"></div><br>
<br>
this is better:<br>
<br>
<div class="thing"></div><br>
<br>
Class is not meant to express an outcome, nor any meaning beyond that
of an identifier. However as an identifier you can use it to associate
more complex declarations of style, script and metadata. Unless I'm
mistaken about your intent it seems these folks may have objected to
making universal class names that have meaning in their own right
(reserved names, class namespaces)? <br>
<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap="">
Except that means you have to coordinate multiple documents, and that
really doesn't follow the goal of having HTML be the carrier of all the
information. That's an important requirement for Creative Commons and
others.

  </pre>
</blockquote>
You would not have to use multiple documents or any code in head. That
is not a CSS requirement nor should it be a metadata one. <br>
<br>
Your choices for creative commons snippets would be something like:<br>
<br>
<!-- SNIPPET --><br>
<metadata><br>
@namespace cc url(<a class="moz-txt-link-freetext" href="http://cc.org">http://cc.org</a>);<br>
.whatever{<br>
    about: url(/whereever/link);<br>
    typeof: something;<br>
}<br>
</metadata><br>
<div xmlns=<a class="moz-txt-link-rfc2396E" href="http://cc.org">"http://cc.org"</a> class="whatever"><br>
    ...<br>
</div><br>
<!-- END SNIPPET --><br>
<br>
-- or --<br>
<br>
<!-- SNIPPET --><br>
<div xmlns=<a class="moz-txt-link-rfc2396E" href="http://wherever">"http://wherever"</a> metadata="typeof: something; about:
url(/whereever/link);"><br>
    ...<br>
</div><br>
<!-- END SNIPPET --><br>
<br>
This proposal requires exactly 1 new element, 1 new attribute, and one
new use of  rel, all of which are reusable for future metadata
extensions. If these proposals do not serve CC's needs then you could
be more explicit about why. Claiming that authors wont like or
understand this stuff seems speculative.<br>
<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap="">
The existing attributes don't do everything we need, as the Primer makes
clear with the use of, for example, @about.

  </pre>
</blockquote>
I realise that, but you're still focused on the need for RDF attributes
rather than exploring other methods. There is very good evidence that
this proposal could serve your stated needs while also being flexible
enough to meet the needs of others and to grow without requiring even
more attributes in HTML6.<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">Since CSS is
familiar to web developers AND already implements the extension and
selection mechanisms to target specific elements and groups it is
superior to RDFa in many ways.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This argument is *exactly* the opposite of criticism we heard during our
open period for comments, that whether @class is a semantic extension or
just a CSS hook, most users think of it as purely a CSS hook.
  </pre>
</blockquote>
<br>
Those users are wrong. One day they will learn otherwise, whether
through this proposal or some future use of class (ie,
getElementsByClassName). For most users the distinction won't even
matter.<br>
<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap="">
Plus, it's *not enough* to express the full range that we need.
  </pre>
</blockquote>
<br>
The spec says that class is not supposed to *express* anything. It is
an identifier of group membership. It is no different from how
operating systems assign users to groups and then assign rights to
groups. Whether this is commonly understood or not is irrelevant.
class="red" does *not* make something red.<br>
<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap="">
That's one extra level of indirection, which makes things more complicated.

  </pre>
</blockquote>
So what? Metadata is complicated. The only issue is how and where the
complex information is recorded. It's the same logic as putting your
details in your drivers license record instead of tattooing them on
your forehead. If the police require the information they use your
drivers license or social security number as an identifier. In this
case @id or @class are the identifier. If you really insist on painting
your metadata across your structures then use the proposed @metadata
inline attribute.<br>
<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">* You can specifically target elements by class and id. The primary
benefit is more clarity or specificity.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
One extra level of indirection doesn't make anything clearer. That's the
criticism we heard about CURIEs, and Manu explained well why we think we
gain from CURIEs more than we lose.

In this case, you're proposing indirection that gains us nothing, since
@class will still have to provide some semantic meaning that is *then*
mapped to more generic semantics in a separate file. What's the gain? 
  </pre>
</blockquote>
<br>
Once again my response is that class is not supposed to "provide
semantic meaning"
and metadata is not required to be a separate file. This seems a common
thread in your arguments. Class is a grouping attribute with no
meaning. No attempt is ever made by the spec to
process class for any purpose other than CSS targetting and some
javascript actions. In both cases being
'human-readable' or 'meaningful' is a happy bonus, not a requirement.
class="udrFGvc8734" is perfectly valid.<br>
<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap="">There's no real separation of concerns, unlike with CSS.
  </pre>
</blockquote>
<br>
Of course there's a separation of concern. Metadata is not a
requirement of valid HTML nor even useful for a large number of sites.
Metadata "pollutes" clean code in the same way as inline style
attributes.<br>
<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <blockquote type="cite">
    <pre wrap="">* You can store the metadata locally or remotely and in any format (ie,
RDF, ID3) that can be parsed by the agent to key/value pairs.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Key/value pairs are not enough. We need the subject, too. Triples.

  </pre>
</blockquote>
<br>
By 'subject' I assume you mean scope (or namespace). Scope is something
CSS provides with nesting, adjacency and multiple classes on an
element. But since this metadata proposal is *not* CSS it can probably
provide whatever additional extensions or scoping are required.<br>
<br>
Also I wasn't aware of this until now but CSS3 actually does provide
namespace support. <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/css3-selectors/#typenmsp">http://www.w3.org/TR/css3-selectors/#typenmsp</a><br>
<br>
CSS examples:<br>
<br>
@namespace foo url(<a class="moz-txt-link-freetext" href="http://www.example.com">http://www.example.com</a>);<br>
 foo|h1 { color: blue }<br>
 foo|* { color: yellow }<br>
 |h1 { color: red }<br>
 *|h1 { color: green }<br>
 h1 { color: green }<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">* The structure and metadata can be separated. The benefit is both the
metadata and the HTML are cleaner and easier to maintain.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
As I mentioned above, I don't buy this argument one bit. You still have
to assign @class, which is effectively an indirection on the metadata,
but really is another way of expressing (a limited amount of) metadata.
So there's no real separation of concerns.
  </pre>
</blockquote>
This is the same argument as above, just rephrased. Class expresses no
metadata beyond group membership. There is also no requirement on
@class at all. @id, tag names and other selectors are equally good.<br>
<br>
This argument is the same for class vs. inline CSS. As a designer I've
found time and time again that class is generally a much cleaner and
reusable construct than style="" inline. Class is simply a method of
grouping related elements. It works for CSS and it can work for
metadata. The spec allows a single element to have multiple classes so
an element can have multiple associations from both metadata and style
sets:<br>
<br>
<style><br>
.boxed{...}<br>
.title{...}<br>
</style><br>
<br>
<metadata><br>
@namespace foaf url(...)<br>
foaf|.title{...}<br>
</metadata><br>
<br>
<div xmlns="foaf" class="title boxed">Engineer</div><br>
<br>
These could also be implemented using <link rel="namespace">
which has been proposed as an alternative or companion to xmlns in some
w3c whitepapers.<br>
<blockquote cite="mid:48B6478B.4070901@adida.net" type="cite">
  <pre wrap="">
@class may be a semantic extension for HTML, but CSS is not. It's
Cascading *Style* Sheets, so your proposal tries to to fit a square peg
into a round hole.
  </pre>
</blockquote>
Now you're being silly, nobody is proposing putting metadata in a
<style> block or using CSS style properties. The point was made
that CSS has a syntax and behaviour that may be useful for applying
things other than styles to objects. Without resorting to analogies
what is your evidence that CSS behaviour or syntax is unsuitable for
reuse? I believe the reason the OP mentioned CSS and the reason I
support it is that vendors may reuse existing parser and selector code;
and designers are all familiar with its syntax (providing a better
basis for discussion). It's a fairly light language and easy to embed
within HTML blocks and attributes. It was designed for that.<br>
<br>
<br>
My objection to being forced to put metadata on an element is largely
to do with the fact you dont always have that option. Many CMS or web
programming languages will generate tags without fine-tuned control
over the tag attributes. I'm sure there are many situations where the
content you're trying to tag is not able to receive the new attributes
you are proposing. In these cases the metadata *needs* to be targeted.
CSS selectors may not always be able to do it, but they still stand a
good chance.<br>
<br>
<metadata><br>
/* Except for the property names this is valid CSS3 */<br>
.foo option[value="1"] {typeof: "movie:actor";}<br>
.foo option[value="2"] {typeof: "movie:title";}<br>
.foo option[value="3"] {typeof: "movie:director";}<br>
</metadata><br>
<br>
<!-- generated list from <cfselect query="sql_data">
(Coldfusion), no additional attributes possible on each <option>
--><br>
<p>Request information about:</p><br>
<select id="foo"><br>
    <option value="1">Indiana Jones<br>
    <option value="2">Raiders of the Lost Ark<br>
    <option value="3">George Lucas<br>
</select><br>
<br>
Shannon<br>
</body>
</html>