[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Compound processing
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 almost. 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: root -> 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 OpenDOC) 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|