[microformats-discuss] Re: Educationg Others

[Ryan King]

On Oct 4, 2005, at 3:58 PM, Danny Ayers wrote:
> On 10/5/05, Ryan King <ryan at technorati.com> wrote:
>> On Oct 4, 2005, at 2:01 PM, Scott Anderson wrote:
>>> On 10/3/05, Ryan King <ryan at technorati.com> wrote:
>>>> On Oct 3, 2005, at 6:47 PM, Scott Anderson wrote:
>>> A content provider may want to add many instances of microformats
>>> within a single XHTML document. There could be multiple instances  
>>> of a
>>> particular type of microformat in this document and some microformat
>>> instances could be related to each other in some way. Say I want to
>>> create a tool that understands the content in XHTML documents that
>>> support microformats. As I see it, the only information I have
>>> available for understanding the meaning of one of these microformat
>>> instances is its "xhtml context"; where in the document the data
>>> resides. This context could be interpreted by starting at the
>>> microformat element and walking up its parent elements capturing  
>>> their
>>> name, class, and other attributes along the way.
>>
>> Um, this is still theoretical, not concrete. But let me try to answer
>> anyway..
>>
>> Sure, "microformat instances" can relate to each other- they can be
>> included within each other and be linked to by each other. Context
>> may be important in some applications, but the context information
>> necessary for each application will be different, and therefore
>> determined by that particular application.
>
> I think Scott's points are valid - it's easy enough to see how simple
> examples of microformat data in documents can be interpreted, but what
> happens when there's lots of interwoven data in a document
> (potentially from different microformats)?

Its tough to talk in the theoretical here– we can't design solutions  
for situation which may or may not occur sometime in the future.

> I don't think faith is much help.

Neither do I.

> The context information necessary for each application *may* be
> different, but much of the idea behind standards is, well to
> standardize, enable the sharing of information and hence enable
> communication. Where any particular format draws the line between
> shared language and per-app interpretation - that would be an
> ecumenical matter.

I've still not seen an example of a microformat which needs to have  
explicit context outside of itself.

And, sure, Danny, if/when there comes a time for standardizing this,  
we can- but there's nothing to standardize yet.

> As far as I can tell, and as Ryan's statement suggests, above a
> certain level of complexity (as specified in the domain models),
> basically microformats are stuffed. The interpretation (and any
> context) does have to be decided at the application level, and clients
> and servers will have to agree on that interpretation, rather than any
> more generally shared data language. This is a weakness in
> microformats as a general solution to conveying data in markup.

I think Kevin's response covers this area well.

> But I believe it's a fundamental mistake to view them as a general
> solution to data transport in any case.

No one's arguing that micformats are general solutions, but, rather,  
a series of specific solutions.

We purposely target the 80/20 (or 90/10) ratio.

> There's a particular range of
> tasks for which they are optimal on today's Web compared to other
> formats. Another useful tool in the kit, no more no less.

As are all tools.

-ryan

--
Ryan King
ryan at technorati.com