[microformats-discuss] Profiles, what are they good for, why do we need them, and how should they be implemented

[brian suda]

Bud Gibson wrote:

> On Jul 15, 2005, at 11:08, brian suda wrote:
>
>> This is why a generic universal validator would be handy, but XMDP is
>> meant for human-readbility first, and machine-readablity second. So
>> somethings people are trying to make microformats do are just out  of
>> the
>> scope of possiblities, lets not forget this.
>
>
> Probably, but it begs the question of what you think are in and out 
> of scope of possibilities.  I think, given your extensive experience 
> and leadership, that that would be useful information.

With the current set of tools, there are just certain things that cannot
be achieved. This does not mean they are impossible, just not feasible
with the current implementations. For example:

XFN is a very simple microformat. There is no nesting of properties like
hCa* ('work' is a sub-property of 'tel', which is a sub-property of
'vcard') and there are few places the resulting data can be stored (with
hCa* things can be in the 'title' attribute in the case of abbr, or the
'href' or 'src' or 'node value'). XFN is on rel="" attributes only and
their value is the corresponding href="". So it looks very simple. If we
dig deeper into the english prose that accompanies each property we find
addtional text like: Often symmetric. Symmetric. Not transitive, No
inverse, etc. These 'constraints' are not represented in any machine
readble form. Partly because there is no way to enforce XFN between two
sites. (If you add my site as a rel='met' i have no requirement to link
back with a rel='met' even though that property is transitive.) and
because it was never addressed or part of the original intent. (i never
worked on XFN or XMDP, so someone else might clarify that last
statement, but i know i have talked with Tantek if it would in any way
possible to add it)

Other things that XMDP cannot do that XML schema can do is custom data
types, or even simple data types.  Right now in hCa* all dates should be
a UTC date format. This is explained only in the english prose reference
to the actual RFC. XMDP provides no way to enforce a YYYY-MM-DD style
string or a $___.00 money string, or int, float, string, double, etc.
All of which, other schema languages can. This doesn't make XMDP bad and
worthless, they are just out of the scope.

Ontologies are another item that is not available in a machine readable
format. To say that this hCard class='url' is the same as a hCal
class="url", or that FOOBAR realestate class="title" is NOT the same as
Dublin Core class="title". This is easily handled in the prose, but not
in the XHTML.

> I would think the XMDP might be a starting place for coming up with 
> validation rules as you have done.  It's more a terse kind of author/
> developer documentation than a tool for validation.  Developers could 
> create rules for validation (a la schematron) from them.

i'm not sure what you mean here?

> Let me point out that I think one problem we are having here is 
> considering the very general case.  A lot of the issue in recognizing 
> microformats comes from having multiple microformats on a page with 
> all the potential for collisions.

very true. I just point them out to keep people aware of potential
problems (not because i have any answers). Most of the feedback and
questions i have fielded about microformats have been more about how to
even get started... no one has had problems with TOO MANY encodings.

> Let's consider that this might not always be the case, and in fact 
> will likely not be the case.  If a page contained only one kind of 
> microformatted content (say xFolk or hCard), then the recognition and 
> parsing issue starts to become a lot easier.

This is certainly true, but i personally would prefer to build a more
general case parser validator especially if this will more of a
bottom-up style design where anyone can be creating XMDPs and
Microformats without a consenses or committee.

Are there any thoughts about this? i have thought long and hard about
how any and all of the above could be built with simple XHTML
technologies and avoiding too much complexity, without much luck.

-brian