Andy Mabbett wrote: > >Which means that URI profiles are /effectively/ required if > you want to > >be assured that standards-compliant parsers will pick them up your > >microformats. > > > >Yea! I think profiles are great. So, why not formalize the > >requirement? > > 1) If profiles are mandatory (or implicitly required by > p*rser behaviour), what happens to people who cannot edit the > "head" element (blog or CMS users, for instance)?
Without meaning to sound flippant, they should convince their tool providers to support microformats. It would take some effort, but blogs or CMSs or whatever can either provide access to the HEAD tag or some mechanism for specifying which microformats are in use and adding the required profiles into the HEAD tag itself. When new technology is deployed, there is generally a transitional phase where it takes developers to make things work. Once the tools catch up, even non-techies can be a part of it. There's no real reason not to expect that transitional phase to be a part of microformats' adoption. My understanding is many of the tools out there are already working on some sort of microformats support, this is just another example of it. > 2) Rather than having a profile for each uF (and, presumably, > near-duplicate profiles for nested uFs such as geo or adr in > hCard?) why not have one over-arching profile for all microformats? If you want an XMDP for that, I'm not sure how it would work. I think it would be a pain to maintain. If you just want to use the profile to indicate that "official" microformats exist on the page without dereferencing to an XMDP, it /could/ work, but non-resolving URIs appear to be contrary to the spirit of the XMDP spec[1]: == User agents may dereference the URI and perform some activity based on the actual definitions within the profile (e.g., authorize the usage of the profile within the current HTML document). This specification does not define formats for profiles. == Although "may" could mean that given agents also /might not/ dereference a given profile URI, the rest of the language indicates that it is expected that you can dereference the URI. Perhaps more relevant is non-resolving profile URIs make sense for us. After thinking about it for a bit, it probably makes more sense to require them to resolve, helping close the loop on "officialness" for any particular microformat. Come to think of it, it seems we should probably add creating an XMDP profile to the process? Perhaps as part of the specification stage? Or after it once a spec has been accepted? -j [1] http://gmpg.org/xmdp/description -- Joe Andrieu [EMAIL PROTECTED] +1 (805) 705-8651 _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
