[microformats-discuss] Re: Educationg Others
Lisa Rein
lisa at lisarein.com
Tue Oct 4 15:40:45 PDT 2005
I understand *exactly* what Scott's getting at here. It's quite
fundamental, really. I think he did a great job at taking a stab at fixing
the problem that I was just about to send an email out on, so here goes.
But first things first. RE: profiles. Then I will get back to namespaces
and/or Scott's elegant attempt at providing context for the different
namespaces using span tags, etc. And demonstrating the need for a unique
ID (URI) for each. Which is our only hope...and, as we've already
discussed, is required anyway by the XHTML/HTML specs...
so first, profiles...OK i finally get it now.
1.
I went and checked out the profile at:
http://gmpg.org/xfn/11
which, although an example document would be nice, does seem to conform to
a profile example on the w3c site:
http://www.w3.org/2002/12/namespace
Note that I'm *not* trying to make a point showing the namespace profile,
it's just that, frankly, there aren't a lot of profiles out there to be
found, and I wanted to find one from "the source" so I would know that it
was conformant.
So, in conclusion, *when these formats have their profiles*, they are
XHTML conformant. Which is good :-)
2. namespaces and mixing markup:
As I mentioned earlier, I still have a question regarding the point that
Scott brought up about using multiple microformats within a single
document, which, if I understand correctly, is kinda the whole point of
microformats.
I don't understand how you would mix domain-specific markup without some
kind of mechanism for informing software about which is which. Otherwise
the different vocabularies have no real meaning to a software application.
(Context is everything when you're dealing with semantics. Otherwise,
there are no semantics really :-)
Actually, Scott's example looks like it could work.
<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>
I was going to ask if the different microformats be defined using multiple
profile attributes within the same HEAD element? But that seems really
messy, and doesn't solve the problem of differentiating the markup within
the page. (I can't tell if it's allowed.)
Would using multiple profile attributes even be allowed? And how would a
user agent able to differentiate between the different microformats if
they all use "rel-tag" method?
Is there perhaps an example of using multiple vocabularies in action, so I
may practice implementing it. I'd like to get started on the video
metadata microformat examples, and I would like to incorporate another
microformat within the example to demonstrate how this would be
accomplished.
thanks!
lisa
> 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
>
>
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss at microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
Lisa Rein
http://onlisareinsradar.com
http://www.widehive.com
http://www.lisarein.com
More information about the microformats-discuss
mailing list