[microformats-discuss] Re: Educationg Others

Tue Oct 4 15:15:00 PDT 2005

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:
>>
>>> I dynamically build my XHTML documents from a mixture of content  
>>> data
>>> and presentation data. The content markup typically gets wrapped by
>>> layers of presentation markup. It could be that the only data I want
>>> to publish as a microformat is the author of a single deeply  
>>> embedded
>>> component. How do I persist the context of the microformat instance
>>> that includes the author's name when the  presentation is now  
>>> part of
>>> the context of that component? It is also typically the case that  
>>> the
>>> presentation markup outweighs the sematic content market by 100  
>>> to 1.
>>> And the presentation is simply a snapshot that could change for
>>> whatever reason invalidating the persisted context that was  
>>> presented
>>> to the user.
>>
>> I don't follow you here. A concrete example would be more useful.
>
> 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.

> In a world where every XHTML document is semantically legible this
> would not be a problem. This is not the world we live in and it will
> not soon change, if ever. So here I am with this "xhtml context" that
> includes a lot of pretty useless information that could change for
> reasons that have nothing to do with how a human would use contextual
> information to logically interpret the meaning of a particular
> microformat instance. I want
> content providers and designers to be able to establish a "semantic
> context" for a microformat instance that is independant of but related
> to the actual "xhtml context" of the microformat instance.
>
> You wanted an example. Say I defined a "semantic context" to be a
> microformat implemented as a span element with class="context"...
>
> <body>
>    <span id="help" class="context">
>       [help controls presentation + help content references defined
> with microformats]
>    </span>
>    <span id="navigation" class="context">
>       [navigation panel presentation + navigation controls defined
> with microformats]
>    </span>
>    <span id="workspace" class="context">
>       <div class="tabbed-panel">
>          <span id="tools" class="context">
>             [tool bar presentation + tools defined with microformats]
>          </span>
>          <span id="content" class="context">
>             <span id="0" class="context">
>                <div class="folder>
>                   [...]
>                   <span id="author" class="context">
>                      [microformats about author of content-0]
>                   </span>
>                </div>
>             </span>
>             <span id="1" class="context">
>                <div class="folder>
>                   [...]
>                   <span id="author" class="context">
>                      [microformats about author of content-1]
>                   </span>
>                </div>
>             </span>
>          </span>
>       </span>
>       <span id="ads" class="context">
>          [presentation provided by adivertising service + ads defined
> with microformat spam]
>       </span>
>    </div>
> </body>
>
> <body> can be seen as a default semantic context. I suppose so could
> <head>. Semantic contexts would not be needed for simple documents
> containing only one microformat instance or one list of microformats.
> I am trying to throw something out there that is as simple as possible
> to demonstrate a point. I suppose that XOXO lists could be made to
> serve as semantic contexts but the point is that the logical
> (semantic) context stays intact despite changes to the physical
> (xhtml) context.

Whoa. What do we need these contexts for? Which microformats need to  
be enclosed in a specific context?

> The above example attempts to demonstrate the establishment of the
> following semantic contexts. I am going to stipulate that to get this
> to cleanly work I will need a requirement that all microformat
> instances support a unique id.

Good practice, but will not be required.

> However, this may not be necessary to
> still obtain benefits from this suggested enhancement. That said, if
> there were a unique id requirement I could provide my users support
> for subscribing to a semantic context via an Atom feed and they could
> monitor individual microformat instances migrating from one semantic
> context to another within the same XHTML document. Anyway, here is
> that list of contexts...
>
> /body/
> /body/help/
> /body/navigation/
> /body/navigation/history (represents an example path to history
> control, a microformat instance)
> /body/workspace/
> /body/workspace/tools/
> /body/workspace/content/
> /body/workspace/content/0
> /body/workspace/content/1
> /body/ads
>
> BTW, when I was thinking about this solution the topic of
> accessibility kept coming up.
>
>
>>> Microformats would be more useful to me if they each had a standard
>>> xml schema,
>>>
>>
>> They do, XHTML.
>>
>>
>
> I still need to personally teach my software to understand each and
> every new microformat that I want to support. It would be better if
> the software could read a schema that captured the semantics of a
> microformat and thus teach itself the meaning of new formats as they
> appear.
>
>
>>> if microformat instances required a unique id in the
>>> context of its document,
>>>
>>
>> profile uri's (I know, I know, not all microformats have profile URIs
>> yet, but they should and will)
>>
>
> This would provide tools that consume microformats an indicator as to
> what type of microformat they were dealing with and perhaps an
> opportunity for a hosted schema but that is not what I mean by unique
> id. This would be used to track a microformat instance within an XHTML
> document. It could also be used as a globally unique identifer when
> combined with the URL of its document.

Of course. Nothing new here, I suggest you read the archives on this  
one.

>>> to an XHTML element instead
>>> of serving double duty as XHTML presentation elements. This would  
>>> let
>>> me cleanly repurpose and route microformats around my system without
>>> having to go to the trouble of teaching th
>>
>>
>> argg. My message got cut off here and the mail's not in the archive
>> yet. I have a feeling that you were about to say "...trouble of
>> teaching designers about semantic markup." If that's the case, then I
>> would respond by saying that we actually have rather eager adoption
>> among web designers (assuming they're already relatively  
>> progressive).
>
> Nope, the last sentance was...
>
>
>> This would let me cleanly repurpose and route microformats around my
>> system without having to go to the trouble of teaching the system to
>> understand what they are.
>
> I don't see teaching designers to produce microformats being a
> bottleneck to your solution. I see the bottleneck being the difficulty
> in teaching software to consume and make sense of microformats. It is
> my hope that sematic contexts could help with this bottleneck while
> also enabling new applications for microformats.

I really don't know what you're tyring to get at here, Scott (and I  
don't think I'm the only one not getting it).

I admit, there's a lot to learn with microformats, some of which may  
seem like "koolaid" that must be taken on faith, but trust me, we  
thought a lot of things through and if you question them we're like  
to have thought-out answers.

Whatever it is you're trying to accomplish here, it seems very  
boiling-the-ocean-ish; you still haven't described a concrete usage  
scenario, without which we can't really talk about solutions.

-ryan

--
Ryan King
ryan at technorati.com