[uf-discuss] Re: DOM scripting as an alternative to include-pattern?

Michael Leikam leikam at yahoo.com
Mon Jun 5 10:27:56 PDT 2006


Thanks.  You're obviously more familiar with designing data
formats than I am, but could you (or anybody else really)
explain a little more about the differences you see between
supporting DOM manipulation during the parsing, as I've
suggested, and supporting include-patterns?

To me include-patterns seem like a subset of DOM and both
seem less to do with the data format itself than the
inherently procedural transformation from one format to
another.  What is the difference between defining a data
format and defining what people do with that data format
(i.e., what that data format is used for)?

I do see the benefit of having an <object> within a
microformatted block of content.  There isn't a process
that needs to run in order for the syntax to reflect the
included data.  It's also more scanable by human eyes than
a block of javascript or xsl.  But in order for the parser
to generate the target format, you've defined this
if class is "include", grab the referenced node including
descendants and replace the current node with the
referenced one.

I guess at root I'm unclear about whether maxims regarding
data formats also apply to data parsing?  The parallel I
see is microformat:parsing::XML:DOM. You want to avoid
procedural rules in the X(HT)ML, but the DOM exists to
formalize them. Is that faulty?

The sort of markup I had in mind was something like this:
<div id="company">
  <div class="hcard">
    <h1 class="fn org">Michael's Webby Widgets</h1>
    <div class="adr">
    <span class="locality">Los Angeles</span>
<div class="hcard" onUFparseEvent="add_org_and_city()">
  <div class="fn">Michael Leikam</fn>
  <a class="email" href="mailto:me at foo.bar">
When parsed, the second hcard would be transformed to the
following before being mapped to vCard fields:
<div class="hcard">
  <div class="fn">Michael Leikam</fn>
  <div class="org">Michael's Webby Widgets</div>
  <a class="email" href="mailto:me at foo.bar">
  <div class="adr">
  <span class="locality">Los Angeles</span>

I don't really want to include the entire div#company since
it includes fields that already exist in my personal block,
e.g., "fn".  Adding an ID to span.locality, which I think
is how include-pattern wants to handle this, isn't
appealing because I'd want to use a generic hcard generator
for any contact information. The base markup is perfectly
available to search engines or the most basic of browsers.

I also see the benefit of advocating limited solutions for
real problems.  That's a very good goal.  I really wasn't
expecting the community here to say "oh, ok, we'll add DOM
support tomorrow."  There's clearly more in terms of
thought and use-cases that would need to go into deciding
whether it's actually a good solution to real problems we
face in marking up our content.  But from the replies I've
gotten, it sounds like this is the beginning of a
discussion and not something that is already ongoing.


[1] http://www.w3.org/TR/DOM-Level-2-Core/core.html

--- Tantek �elik <tantek at cs.stanford.edu> wrote:

> Michael,
> First of all welcome.  Glad to hear you are trying things
> out with hCard and
> hCalendar, and thanks for reporting where you have found
> challenges.
> Feel free to document the issues you run into on the
> respective issues
> pages, e.g. http://microformats.org/wiki/hcard-issues
> Regarding some of the thoughts/proposals.
> It is a well known maxim in data format design circles to
> avoid procedural
> aspects in data formats completely if not as much as
> possible.
> In addition, the argument for including more features
> requires
> justification, not the lack of a justification.
> The object-include pattern solved the precise need that
> arose in-common
> among hReview and hResume, and even in those cases, as a
> result of actual
> experience working with the formats and iteration.
> Any kind of scripting/programming MUST NOT be included as
> even an optional
> portion of a data format (with the one exception of a
> completely opaque
> chunk the handling of which is left to outside the
> specification, e.g.
> javascript: URLs, or image formats in photos which may
> themselves contain
> scripts) in order for the data to be maximally safe and
> most easily consumed
> by search engines and browsers alike.
> Thanks,
> Tantek
> (IMHO we may want to consider adding this as an FAQ).

More information about the microformats-discuss mailing list