[uf-dev] Microformat Object Models (was: Finalizing jCard)

[anders conbere]

On Tue, Apr 15, 2008 at 6:42 AM, Ben Ward <lists at ben-ward.co.uk> wrote:
>
>  On 15 Apr 2008, at 13:57, Brian Suda wrote:
>
> >
> > > I would say that there exists no such function g() which allows for
> jCard -
> > > or anything *like* jCard - to be defined in those terms, thus it is
> > > justified to dedicate effort into defining jCard explicitly.
> > >
> >
> > --- the other thing i think we are hung-up on is solving the JSON
> > representation for a single format. We have several design patterns to
> > map VCF/ICS data to HTML, the class design pattern, the rel-design
> > pattern and others. IMHO This is the best way forward to map
> > Microformatted HTML to JSON in a similar manner, through patterns -
> > not specific formats. Lets not worry about XYZ format mapping to JSON,
> > we should look at a mf2json() mapping.
> >
>
>  •• Defining 'jCard' explicitly is a perfectly valid effort, but within the
> microformats community — — where we're working within the scope of HTML ——
> the focus is to solve the problem of parsers producing inconsistent output,
> hence my emphasis on this being the 'hCard Object Model' (vis a vis the DOM,
> CSS OM). My view is that If that effort produces a defined vCard in JSON
> format as well then so be it, but for me, the lack of a vCard->JSON format
> is not the problem itself.
>
>  • Object Model consistency needs to be fixed for all other microformats,
> too, which gives weight to Brian's generic approach. If a set of generic
> parsing rules and patterns is robust enough and can be documented tightly
> enough to be implemented, then it's probably the way to go.  Should we
> perhaps be looking to better define the data types at a schema level, which
> then map to parsing rules?

Dan Brickley and I had a couple of good conversations at BlogTalk
about how microformats could really use an assertion based approach to
parsing. If you see every data item as a claim then everything becomes
tuples.

(Anders Conbere, has a, Hcard)
(Hcard, has a, Address)
(Address, has a, Street)
(Street, is, 7511 Jones Ave NW)

When you organize data structures like this it becomes trivially easy
to define what a correct set of claims are for any given microformat
and test for the correctness of a parsing output.

Some of you might recognize this as the stance the rdf takes with it's testing

http://www.w3.org/TR/rdf-testcases/

when I brought this up a month ago there was some strong push back
from tantec for what I felt was a reluctance to begin to solidify the
definitions of what is a very loose set of specs.

That being said, it's REALLY REALLY hard to parse microformats
properly today, having a test harness to run my parser against would
help immensely, but that requires the organization to put some work
into solidifying the way the specs work.

(One of the other nice things about specing your formats as rdf, is
that you can easily create grddl documents for them and parsers are
really good at parsing rdf.)

~ Anders




>
>  To Glenn Jones: You said you might have an example of the kind of model
> documentation you'd like to implement against. Were you able to find any
> examples of this?
>
>  B
>  _______________________________________________
>  microformats-dev mailing list
>  microformats-dev at microformats.org
>  http://microformats.org/mailman/listinfo/microformats-dev
>