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

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