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

[Ryan King]

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