profiles, yes; taking back, no [was: Re[2]: microformats, profiles, and taking back rel/class names [standardizedFieldValues-51]]

In my recent post I tried to establish the case that semantics for 
@class, linked
through @profile (either page-global in HTML4 or more locally in HTML5), is
backward-compatible.

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

Now I'd like to take on a slightly broader horizon.

In his initial post, Dan muddied the waters by leaping to a draconian step:
taking loosey-goose tokens under spec control.  That's not implied by
the milder step of establishing a preferred way of exposing interpretation
guidance for the author-controlled tokens in attributes that allow such.

There are cases where concepts need to be migrated from crowd-sourced
standing to spec-sourced standing.  The justification would have to be
an exigent need, comparable to the legitimate use of "taking by eminenet
domain."  But in this case new signs for  the newly-controlled senses *are*
a better way to go.

Step 1:

Make it clear that it's cool within @profile (or <link
rel="dcterms:conformsTo" ...> or whatever) to introduce references to
data dictionary documents explaining @class and @rel/rev values in
addition to values of meta.name.

Step 2:

There will take some time to see if we get any takeup of data dictionary
practice.

Step 3:

There will take some further time for a shakeout in data dictionary languages.

Step 4:

shortnames in the domain of distributed coinage and glossarization as above
will, through viral propagation and genetic competition, develop some
common usage.

HTML could, as an efficiency measure, introduce, by spec provision, a
dictionary of the most stable of these into the collection of data
dictionaries cited in @profile *at the low precedence end of the
pecking order* comparable to the 'initial' values set by language
default in CSS, that lose out to all other defaults and values set
more specifically on a case by case basis.

Step 5:

In some cases, meanings associated with terms formerly crowd-sourced
will have processing or trust dependencies that make an irrefutable case
for bringing them under control.  The problems vexing the Web Security
Context WG at present suggest one domain of practice where this could
happen.

In these cases, as Mark argued, there is reason to introduce new
signs for the newly-controlled senses.  If there's no version checking,
then there should probably be new markup, amenable to discrimination
with existing selectors.

But the simple fact that people aren't checking the data dictionaries
for terms that look familiar, that's not sufficient justification for
the more radical step. Best to leave the semantics that processors
don't honor in the crowd-sourced bucket; rather than be subjected to
the ignominy that nobody is paying attention to the format spec
proper, all over again, just the same.

The spec can, for established usage, play nice and beneficially in
the crowd-sourced puddle, if it takes a humble enough seat at table.

Al

Received on Friday, 20 July 2007 12:27:47 UTC