On Sun, 2006-04-23 at 12:15 +0200, Danny Ayers wrote: > On 4/23/06, Benjamin Carlyle <[EMAIL PROTECTED]> 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 _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
