[uf-discuss] lc:format/@type = html profile? Was: Announcing Live Clipboard v0.92

[Benjamin Carlyle]

On Sun, 2006-04-23 at 12:15 +0200, Danny Ayers wrote:
> On 4/23/06, Benjamin Carlyle <benjamincarlyle at optusnet.com.au> wrote:
> > My suggestion is that the type attribute (in addition to contenttype)
> > appears both unneccessary and unuseful to my cursory understanding of
> > the problem domain. I may be missing something, so I am interested to
> > hear reasons why it should be included and when it should be included.
> I was wondering about @type too, but from a slightly different angle.
...
> Regular "standalone" uFs documents are disambiguated by the use of a
> profile attribute on xhtml:head. This contains a URI, identifying the
> uFs in use (few of the profile URIs have been minted yet, but the
> intention seems to be that the use of these will go into the specs).
> Full disambiguation of microformat data in document fragments is a
> known issue - if you don't have xhtml:head, there's not really good
> place to put the profile URI.

That would be an interesting use/replacement of the type attribute.
Using existing URI reference or short string registries may permit it be
used in formats other than html, too. It could be a generic "set of
tokens dependant on contenttype that indicate further the type of data
held within". So for microformats it could indicate the profiles as:

type="hcard hcalendar"
or
type="http://www.w3.org/2006/03/hcard some-hcalendar-profile"

An rdf document may be identified as
type="http://xmlns.com/foaf/0.1/ http://xmlns.com/wot/0.1/"

The minimal change to the specification would be to explicitly allow
space-spearated tokens and probably leave it up to the user community to
decide on the meaning of the tokens and the sets they support.

Now, that rdf example seems strange. The reason is that rdf already
handles namespaces and identity conflicts internally.

So do microformats.

For this reason I don't think the type attribute should be used to
specify the different microformats within the document, but what about a
notion of indicating the existence of -some- microformats in the
document:

type="http://microformats.org/"

?

> 1. leave as-is (maybe include a note of space-separated values)
> 2. get rid of type, defer to whatever attributes are in the uF payload
> 3. strengthen type's disambiguation - maybe by including profile URIs
> in the type attribute, or even replacing it with an optional profile
> attribute, directly modelled on that of microformats (i.e. XHTML).
...
> There is of course the other issue - that few of the microformats have
> profile URIs yet. I so so hope this'll be resolved soon!

I think the question of profiles in microformats is still possibly an
unanswered one. They have come suprisingly far without them, and this is
because:
1) As with rdf, the microformat identifiers (class names) have been good
enough for disambiguation between the microformats themselves
2) The microformat identifiers have been good enough for disambiguation
with ad hoc non-microformat content
3) There has been no organised alternative identifier scheme produced

Microformats have so far generated a great deal of good will and
cooperation. Whether they continue to do so forever is a question that
may be relevant to how the type attribute is used. Is it necessary to
indicate that microformat content is in use (as opposed to the formats
of another organisation)? Is it necessary to indicate which microformat
content is in use (will conflict come into the microformat world)?

It is unclear whether the avoidance of namespaces will harm microformats
more or less than the acceptance of namespaces has harmed rdf.
Namespaces seem necessary from a technical perspective, but there is a
question as to whether there is a technical problem to solve. It may be
a social one, and a social problem may not respond as expected to the
obvious technical solution[1]. It may be that we won't know whether
namespaces of the form we use today are a good idea until our
grandchildren pick up the pieces.

In particular:
1) By identifying microformats.org formats and allowing for
alternatives, are alternatives encouraged?
2) By identifying different microformats in the header, are differening
meanings for thigns like "vcard" encouarged?

My personal feeling is that the current microformat trajectory should
continue. Wherever the term is found it is assumed to be the one from
the controlled microformat vocabulary. Profiles should essentially be
ignored despite intentions to get around to them eventually. I think the
type attribute should be dropped for microformats. Consumers should work
without it, and will often want to ignore what a producers says
something is anyway. Producers often get such details wrong when they
are redundant to correct processing.

I think it is reasonable to specify the type attribute generically,
because there may be uses for it. Those uses should be able to leverage
a common base specification. I think the specification should explicitly
permit a token list that may include URIs.

There may be an argument for requiring producers to supply a type
attribute now as defined by for a particular content type (even for
microformats). It may be reasonable to relax the requirement if we then
find that consumers don't need it in practice. That would mean working
out which tokens to use for microformats and other content types as soon
as possible. I would specify that producers "must" supply the type
attribute, but that consumers "should" be able to handle the absence of
the type attribute. The risk that a useful class of applications is
excluded when producers don't supply the type attribute should be
measured and compared to the effort in conforming to that "must". I
would weigh the risk as low and the effort at least at "nuisance" level,
but I'm sure other opinions are out there.

Benjamin.
[1] http://soundadvice.id.au/blog/2006/04/11#namespaces