W3C home > Mailing lists > Public > www-tag@w3.org > July 2007

Re: microformats, profiles, and taking back rel/class names [standardizedFieldValues-51]

From: Harry Halpin <hhalpin@ibiblio.org>
Date: Tue, 17 Jul 2007 15:46:38 -0400
Message-ID: <469D1C9E.9060609@ibiblio.org>
To: Mark Baker <distobj@acm.org>
Cc: noah_mendelsohn@us.ibm.com, Dan Connolly <connolly@w3.org>, www-tag <www-tag@w3.org>

Mark Baker wrote:
> On 7/17/07, Harry Halpin <hhalpin@ibiblio.org> wrote:
>> Why not instead of
>>
>> <div class2="http://example.org/human-resources/employee">
>>
>> just do
>>
>> <div class="employee" profile="http://example.org/human-resources/">
>
> Because no software which knows of @class knows about @profile, making
> that snippet semantically identical to this one;
>
> <div class="employee" profile="http://example.org/foo/bar/">
No software which knows about @class knows about the theoretical new
"@profile2" either. Software won't know about it unless 1) it's in the
spec  and 2) software uses it to produce value, sort of in that order.
Since neither @profile or the theoretical @profile2 is in the spec,
@profile is the clear winner, even if it has to remain in the header,
since at least @profile is in HTML 4.
> Using a new attribute makes it unambiguous.
Using @profile is just as unambiguous. Changing new string names does
not make something unambiguous unless the previous string name is
already deployed at that location in the HTML|XML file, which neither
@profile or the theoretical @profile2 is.

 At least with @profile you are building off something and/or extending
something in HTML 4, instead of inventing whole new attributes to do
something a previous attribute in HTML 4 did.

I see no reason to reinvent the wheel,  as there is no semantic gain
from changing string names.


>
> Mark.


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426
Received on Tuesday, 17 July 2007 19:47:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:46 GMT