W3C home > Mailing lists > Public > public-grddl-comments@w3.org > July to September 2008


From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 25 Aug 2008 23:02:15 +0200
Message-ID: <48B31DD7.8050809@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: Harry Halpin <hhalpin@ibiblio.org>, Danny Ayers <danny.ayers@gmail.com>, Dan Connolly <connolly@w3.org>, "Booth, David (HP Software - Boston)" <dbooth@hp.com>, "public-grddl-comments@w3.org" <public-grddl-comments@w3.org>

Ian Hickson wrote:
>> So is head/@profile.
> No, <head profile> is intended to be an opaque identifier declaring that a 
> vocabulary is in use. HTML4 doesn't justify dereferencing it for computer 


> processing purposes, and doesn't even allow more than one URI. It's not an 

Not really true:

"This attribute specifies the location of one or more meta data 
profiles, separated by white space. For future extensions, user agents 
should consider the value to be a list even though this specification 
only considers the first URI to be significant. Profiles are discussed 
below in the section on meta data." -- 


"The profile attribute of the HEAD specifies the location of a meta data 
profile. The value of the profile attribute is a URI. User agents may 
use this URI in two ways:

     * As a globally unique name. User agents may be able to recognize 
the name (without actually retrieving the profile) and perform some 
activity based on known conventions for that profile. For instance, 
search engines could provide an interface for searching through catalogs 
of HTML documents, where these documents all use the same profile for 
representing catalog entries.
     * As a link. User agents may dereference the URI and perform some 
activity based on the actual definitions within the profile (e.g., 
authorize the usage of the profile within the current HTML document). 
This specification does not define formats for profiles." -- 

So the only issue is that HTML4 claims that only the first one is 
significant (which is easily fixable), but it does license following the 

> extension point, it has a defined meaning.
>>> from an HTML5 perspective it's fine. The profile="" attribute is worse 
>>> because it encourages other people to make the same design mistake, 
>>> and it
>> Which design mistake?
> The one I immediately described:
>>> misleads people into thinking that they have to declare their vocabularies,
>>> and it misleads people into thinking that other people will declare their
>>> vocabularies.
>> I think it's a good design to declare a vocabulary.
> I understand that you think that.

OK, so let's agree that we disagree.

>>>> Yes, that would be true, but you'd have to explicitly add it to your 
>>>> list of GRDDL transformations. Which is also work.
>>> It's work you will have to do anyway, since not all microChemistry 
>>> users will label their documents as using microChemistry.
>> How do you know that?
> Users have not used profile="" for any of the other vocabularies on any 
> sort of consistent basis, so there's no reason to think they'd do anything 
> different for new vocabularies.

Maybe it's because of lack of vocabularies that used it before?

>>> It's also only work for the GRDDL users who care about microChemistry, 
>>> which is likely less than the number of microChemistry users.
>>>> So, for agents when encountering a profile that has a transformation 
>>>> that is not locally cached, they could "dynamically" run the GRDDL 
>>>> tranformation by going to the profile page.
>>> Only if the profile page declares the GRDDL transformation, which is 
>>> unlikely in practice.
>> Why is that unlikely?
> Based on the existing profiles, it hardly ever happens. It seems 
> reasonable to extrapolate that this will continue to not happen much.

How long has GRDDL been out?

I think you're very quick in jumping to conclusions that fit into your 
world view.

For instance, I've been using "http://www.w3.org/2006/03/hcard" for 
quite some time now as hcard profile, and it does seem it has been 
upgraded to support GRDDL.

BR, Julian
Received on Monday, 25 August 2008 21:02:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:03 UTC