On 3/27/06, brian suda <[EMAIL PROTECTED]> wrote: > > What are you trying to accomplish with directories that would be out of > the scope of hCard?
Like I said: things like protocols and data formats. Version and revision numbers. Publication dates. Specification names and standards organization references. Arbitrary names of services-people-deliver that aren't standard in any way. Some of it could fit into hCard but other parts would be an awkward fit at best. This would be in the context of service discovery: for some resource, or for some organizational context, show me a directory of available or relevant services. If you're familiar with OpenURL resolvers, I'm thinking of something like their result screens, but bigger, and with a usable design and the option to machine-parse reliably. Which is to say, not really like current OpenURL resolver result screens. I don't really want to drop down to UDDI or whatnot... something user-centered is better. Though, I guess stuff like the UIs based on UDDI-driven services in apps like contemporary GIS tools with directories of remote data layers and remote feature processors might be the best examples I know of a current setting where something like what I'm after actually works and has a decent UI. I don't want to try to convince anyone here that there needs to be a microformat for this stuff... I'd just like to know if anybody's tried to do something like this already and whether they chose to "just use hCard" or something else or not at all. And, if it would definitely be wrong to "just use hCard". My hunch is that it would be wrong because most hCard processors likely expect to see information about people and organizations, not information about services and data and stuff. But my instinct is to try it anyway. Thanks. _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
