[microformats-discuss] Re: Educationg Others

Tue Oct 4 14:01:35 PDT 2005

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.

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.

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. 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.

> > 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.