[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Compound processing


applications of coordination compounds
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.