OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Compound processing

[ Lists Home | Date Index | Thread Index ]

On Wednesday 23 January 2002 04:30 pm, Mark Baker wrote:
> > One of the problems with this is approach is the coordination
> > between different elements. Something has to organize these things
> > into a coherent whole.... the summarizer case you gave illustrates
> > this point. If the XHTML summarizer doesn't understand the SVG
> > summarizer, you may not get an accurate summary (for example,
> > perhaps the XHTML says "Be nice!" and the SVG says, in big bold
> > letters "Go away".
> I don't agree with that example; there's no need for them to agree
> on what summarization is.  But generally, yes, there needs to be
> some coordination.  The main objective of my draft is to define
> rules of coordination, and I'd really appreciate some input from
> folks who have had some experience with these systems.

The point I was making is that for the XHTML summarizer (assuming this 
means something that is able to meaningfully summarize the content of 
itself) to do it's job, it needs to correlate the summarization of 
it's constituent/embedded parts... or there is a real risk of them 
being out of sync. Many kinds of processing need this.... there has to 
be a coordination framework there... a well-known set of interfaces 

In OpenDoc, Fresco et al. the processing model is typically very much 
as the current processing proposal goes: start at the outermost 
widget, and ask it to do something. That thing then goes off and asks 
each of it's things to do it's job, recursively feeding the processed 
results of the leaves back to the root. For example, layout in Fresco 
used to go:
            -> how much space do you want
                                -> how much space do you want
                                <- 80x80
                                -> how much space do you want
                                <- 80x80
            <- 160x160
            -> ok, you got 160 x 140
                                 -> you got 80x70
                                 <- ok
                                 -> you got 80x70
                                 <- ok
            <- ok

(Essentially. I am abstracting to protect the innocent).
This was actually based on the TeX model of layout...

The important thing to note here is that there is a set of well-known 
interfaces that the layout engine could call for all the constituent 
components. OpenDOC had something similar, where all OpenDOC 
components had to implement certain interfaces (still have that code 
around somewhere... in case anyone wants a simple XML renderer for 

The same thing applies to XML processing. In the context of a given 
processing application (such as layout), even switching on the 
namespace may not help. What happens if no component that implements 
that processing interface can be found? These kind of questions are at 
the heart of processing, and lead to defining an application, because 
not all applications have the same set of behaviours, *especially* in 
the face of error.

Defining a dispatch model is very good. A useful step, but it ignores 
the problem of *building the application* and *packaging the 
application*... and claims that "we'll just download the code" don't 
really work, because you *still* can miss components.... or you open 
yourself up to the well-known Trojan horse problem with embedded 
downloadable code.

On this, I think Rick is right on the money. One of the biggest 
problems with XML is *not* namespaces, the processing model, or 
<whatever>. It is *deployment*. How do we get the XML content, and all 
the bits necessary for processing it *in an application context* to 
the user? RDDL etc. need to be evaluated in that perspective, I 
believe... or at least in the context of an application.

I would go one step beyond packaging, and claim that what we really 
need is a way to deploy *applications of XML* in a secure manner. For 
people developing {information} products, that is the only way they 
can be sure people consume the data as they intended them to. For 
example, I would like some way of saying, "Mr. Baker may read my 
documents but he cannot view the source"... or I might package my data 
saying that "this is available for online display, display via a 
braille reader, as a spoken document, and as a pdf file. The source is 
not available.".

The thing here is that in most cases, I, as the producer, do not care 
about embedding *except* as it pertains to my application. In the 
scope of an application, with well-known dispatch semantics, and a 
well-known set of components (for example, XML EDI 
processors/gateways), you probably *can* dispatch on embedded content 
reliably using little more than an element lookup table... but you're 
still left with packaging.




News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS