W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2008

[whatwg] Ghosts from the past and the semantic Web

From: Shannon <shannon@arc.net.au>
Date: Fri, 29 Aug 2008 18:31:14 +1000
Message-ID: <48B7B3D2.2070203@arc.net.au>
Ben Adida wrote:
> Shannon wrote:
>   
>> <link rel="vocabulary"
>> href="http://some.official.vocabulary/1.1/metadata.cm">
>>     
>
> 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...)
>   

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.

>
> 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.
>   
I'm referring of course to the behaviour and syntax, not the elements or 
properties, assuming that behaviour were basically the same as CSS.

> 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?
>   

The same way RDFa does except it's done within a metadata block or 
attribute.

> 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.
>   
eRDF is a hack that abuses the purpose of @class. Class was never meant 
to carry meaning beyond group membership.

> 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.
>
>   
Class is not being shoehorned in this proposal. Nothing is being put 
into class except class names.

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.

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.

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.

I think you see the problem to be solved as "RDF-in-HTML". I would 
prefer the problem defined as "Metadata-in-HTML".
> 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.
>
>   
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)?

 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:

<div class="red"></div>

this is better:

<div class="thing"></div>

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)?

> 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.
>
>   
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.

Your choices for creative commons snippets would be something like:

<!-- SNIPPET -->
<metadata>
@namespace cc url(http://cc.org);
.whatever{
    about: url(/whereever/link);
    typeof: something;
}
</metadata>
<div xmlns="http://cc.org" class="whatever">
    ...
</div>
<!-- END SNIPPET -->

-- or --

<!-- SNIPPET -->
<div xmlns="http://wherever" metadata="typeof: something; about: 
url(/whereever/link);">
    ...
</div>
<!-- END SNIPPET -->

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.

> The existing attributes don't do everything we need, as the Primer makes
> clear with the use of, for example, @about.
>
>   
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.
>> 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.
>>     
>
> 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.
>   

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.

> Plus, it's *not enough* to express the full range that we need.
>   

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.

> That's one extra level of indirection, which makes things more complicated.
>
>   
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.

>> * You can specifically target elements by class and id. The primary
>> benefit is more clarity or specificity.
>>     
>
> 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? 
>   

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.

> There's no real separation of concerns, unlike with CSS.
>   

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.

>> * 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.
>>     
>
> Key/value pairs are not enough. We need the subject, too. Triples.
>
>   

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.

Also I wasn't aware of this until now but CSS3 actually does provide 
namespace support. http://www.w3.org/TR/css3-selectors/#typenmsp

CSS examples:

@namespace foo url(http://www.example.com);
 foo|h1 { color: blue }
 foo|* { color: yellow }
 |h1 { color: red }
 *|h1 { color: green }
 h1 { color: green }
>> * The structure and metadata can be separated. The benefit is both the
>> metadata and the HTML are cleaner and easier to maintain.
>>     
>
> 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.
>   
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.

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:

<style>
.boxed{...}
.title{...}
</style>

<metadata>
@namespace foaf url(...)
foaf|.title{...}
</metadata>

<div xmlns="foaf" class="title boxed">Engineer</div>

These could also be implemented using <link rel="namespace"> which has 
been proposed as an alternative or companion to xmlns in some w3c 
whitepapers.
> @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.
>   
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.


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.

<metadata>
/* Except for the property names this is valid CSS3 */
.foo option[value="1"] {typeof: "movie:actor";}
.foo option[value="2"] {typeof: "movie:title";}
.foo option[value="3"] {typeof: "movie:director";}
</metadata>

<!-- generated list from <cfselect query="sql_data"> (Coldfusion), no 
additional attributes possible on each <option> -->
<p>Request information about:</p>
<select id="foo">
    <option value="1">Indiana Jones
    <option value="2">Raiders of the Lost Ark
    <option value="3">George Lucas
</select>

Shannon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080829/2f875139/attachment.htm>
Received on Friday, 29 August 2008 01:31:14 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:05 UTC