On Jun 5, 2006, at 10:27 AM, Michael Leikam wrote:
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?
The problem arises when you ad an imperative (procedural) aspect to
what is currently a declarative (non-procedural) data format.
If you include an imperative component to the data format, you force
user agents (both visual and non-visual (which includes search
engines)) to execute arbitrary *foreign* code- which can cause all
sorts of fun problems. Not the least of which, the Halting Problem
[http://en.wikipedia.org/wiki/Halting_problem].
From the particular perspective of a search engine (which I work
for), this makes a procedural data format a non-starter.
So, you're right in the sense that implementing the inclusion-pattern
may involve using some of the document scripting you're used to
("DOM" in the loose sense), but that should be up to the consuming
agent, not the producer.
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)?
The difference is this: with the current <object>-based include
pattern, *I*, the writer of the consuming agent get to decide how its
implemented– if we include document scripting as a solution to the
include pattern, then I have to run your code on my server, and
that's just not reasonable.
-ryan
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
