If I were to implement an export to vinoXML function at WineLog, I
would treat it very much like a custom RSS feed (only in vinoXML format
rather than RSS). I would put a link or button the page to allow users
to view the data in this format. Aggregators looking for vinoXML would
know to look for the appropriate XML file.
This is how I would integrate vinoXML into WineLog or really any site
where I wanted to make my wine data available for easy aggregation.
e.g. I could see a wordpress plug-in developed that would capture all
the pertinent data and simultaneously output a blog post and
corresponding vinoXML file.
---
Scrugy seems to already take into account microformats when it is
aggregating data. If I include microformats on WineLog data, I will
help Scrugy and other applications that are trying to make sense of my
data. I think Scrugy could probably do this type aggregation through
the vinoXML file instead; it might even be easier. (think of blog
aggregators that read a blog's RSS feed vs. the web page itself)
--
However, there are some cool things you can do with microformats that a
seperate vinoXML file wouldn't be able to do (as easily). For example,
there are browser plug-ins that can detect microformats and do fun
stuff with them. There is even one called "Blue Organizer" which has
some kind of wine recognition capabilities (with select wine websites).
The fact that the HTML data is right there tangled up with the embedded
microformats data makes working with these objects all the more easier.
(1) the application doesn't have to look for and load an additional
file and (2) the application doesn't have to connect the XML data to
the HTML data. It is already "coupled".
---
I think we could choose to try to solve all of our problems with just
one of these techniques (have we defined all of our problems yet?). I
also think we could implement them both together, although this might
overly complicate things. I am fond of microformats for its simplicity
and flexibility. I am fond of the vinoXML approach for its similarity
to RSS, which people seem comfortable working with.
Regards,
Jason Coleman
Co-founder, WineLog.net
Couldn't you image that there is a "datastorage" format and there are
tools which transform it into "html", "xhtml - microformats", "internal
format" etc etc.
This would mean that everyone who supports import/export functionality
uses the "datastorage" format and does his own transformation of that
data to/from their internal data structure and everyone who needs to
present the data on a web page or other form uses his transformation to
present the data and there will be the need to have a "creator" type
(http://microformats.org/code/hreview/creator) web interface to create
the "datastorage".
Looking at Microformat it looks very very generic, I think I understand
why they do this and I also see that it has great value for many
things. But could it handle the wine requirements of a review (maybe
yes), could it handle a tasting (in other words a detailed review), I am
less sure, that type of thing would in my view need an hWineTasting or
something as I think it would have to be able to cover things like:
- Tasting System (Parker, Wine Advocate, WeinPlus-de, La Revue de Vin de
France, Matzner, Johnson etc.......), this one should really also be in
review, just to know that it is 90/100 is not good enough as many of the
above use a 100 point system, but they don't use the scale the same way.
- Description
- Date of tasting
- participants/tasters
- the actual tasting notes, in text form, with or without points
- with sub-sections such as:
- first impression (used by Matzner)
- sight
- smell
- taste
- finish (used by Matzner)
- overall
It should obviously also be possible to create a tasting note somewhere
in between the above a simple form.
Werner