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

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

From: Mark Baker <distobj@acm.org>
Date: Wed, 18 Jul 2007 09:52:30 -0400
Message-ID: <e9dffd640707180652i1a862780hdd45d442c4a9d756@mail.gmail.com>
To: "Harry Halpin" <hhalpin@ibiblio.org>
Cc: www-tag <www-tag@w3.org>

On 7/17/07, Harry Halpin <hhalpin@ibiblio.org> wrote:
> Mark Baker wrote:
> >
> > On 7/17/07, Harry Halpin <hhalpin@ibiblio.org> wrote:
> >> So inventing *two* new things, i.e. a new attribute and a new element,
> >> is superior than simply using @profile as it stands in the header in
> >> HTML 4 and *maybe* expanding it to work off an existing class element?
> >
> > Yes, I believe so.  I'm all for extending existing mechanisms when the
> > extension won't break backwards compatibility (i.e. where existing
> > clients won't misinterpret the meaning of the document).  But the
> > change you're suggesting would confuse them, as I believe I
> > demonstrated with my last example.
> I have to disagree respectfully.  What precisely is confusing with the
> last example and how does it break backward compatibility?

Here's the document snippets which demonstrate the backwards
incompatibility; existing software treats them as semantically
equivalent when they're not.

<div class="employee" profile="http://example.org/human-resources/">

<div class="employee" profile="http://example.org/foo/bar/">

> Perhaps I am missing something, but I find introducing new elements and
> attributes with the same semantics and behavior as previously defined
> elements confusing.

Granted, it will be confusing to some authors.  But I'd rather have
some confusion than break backwards compatibility.

Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
Received on Wednesday, 18 July 2007 13:53:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:52 UTC