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

[Michael Leikam]

Tantek,

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
procedure:
---------
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>
  </div>
</div>
<div class="hcard" onUFparseEvent="add_org_and_city()">
  <div class="fn">Michael Leikam</fn>
  <a class="email" href="mailto:me at foo.bar">
</div>
---------
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>
  </div>
</div>
---------

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.

-ml

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