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

[Bud Gibson]

Thanks, Brian

I think this nicely summarizes in one place the limitations of XMDPs  
for machine validation.  And, as you observe, they were never  
intended that way.  Maybe the list maintainers will use this email in  
some sort of FAQ.

I have sometimes speculated that one could read the prose in the XMDP  
and translate that into some set of rules that could at least  
validate that one had all of the elements, properly nested etc.  That  
kind of idea may be useful for people who want to use microformats as  
data.  For those just attempting to make an incremental improvement  
to markup, it may seem a kind of anathema because it imposes a kind  
of all or nothing burden on web page authors.

Bud

On Jul 15, 2005, at 20:27, brian suda wrote:


> 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
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
>
>