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

1.  I must wish to admit a preferences for the line of reasoning that 
Harry has been following.

a. +1 to saying that there are accessibility use cases for names that 
have definitions behind them.

b. the breakage Mark claims to have demonstrated has no standing.
(all propositions are true on the empty set; his breakage is true on 
an empty set of
functionality)

http://lists.w3.org/Archives/Public/www-tag/2007Jul/0074.html

Everyone seems to be agreed that present processing matches values of
@class with selectors applied in CSS or XSLT without regard to
further reference to any dictionary of terms linked through @profile,
locally or at the root of the document.

This processing depends on a private, out-of-band communication
between the writer of the HTML and the writer of the CSS. It won't
break under the old or new regimes.

CSS selsectors don't work across sites at present, because there is
no sharing of the sense of the @class values.

If we define the path for people to point to instructions on how to
interpret their @class values, nothing breaks, and third parties can
re-use style rules, or re-style, and re-format (see SWAP from
ubaccess.com) content so as to preserve the sense and dodge device
and access hurdles.

The site-of-origin stylesheets will still work. But user and
access-broker stylings can now be fit to the content because the
'why' of the presentation has been shared.

CSS has multi-attribute selectors; so that without changing CSS,
stylesheets can distinguish between

<elem class="foo" profile="bar">
and
<elem class="foo">

** nothing (that works now) breaks **

alll that works now is that same-site stylesheets key off @class and
allocate visual (and in theory aural) semantics.

With the new extension of information regarding the sense of @class
tokens, this will still work. *In addition* cross-site presentation
generation will work with content from sites that use @profile and
back it up with meaningful data dictionary documents at the end of
the @profile references.

Someone said that @class in HTML is 'defined to be meaningless.'
Nothing is farther than the truth. @class tokens at present have
private meanings. What is true is that the HTML spec does not tell us
the meaning of these tokens in anyone's documents.

Linking to definitions for these terms via @profile is an
upward-compatible way to give the opportunity for authors to
go public with the sense of their @class terms.  That's just
adding value; doesn't break anything that works today.

Extending the applicability of data dictionary documents linked
through @profile to governing the interpretation of @class as well as
meta.name is a friendly, and compatible with current functioning,
extension of the semantic depth of the web.

2.  This message says nothing about whether
(1) curies or
(2) @profile + data dictionary documents
... are [preferable | desirable | miscible | etc ].

I am only here addressing the more narrow issue of continuity
as it relates to adding semantics through data dictionaries
cited in @profile that disambiguate the interpretation of @class tokens.

I do conclude that (2) above is not only feasible but compatible
with the extant web.

[It's a way for the content author to subscribe to community sharing
of reusable concepts above and beyond what is in the W3C
specification.]

Al

Received on Friday, 20 July 2007 02:31:08 UTC