[
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
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.
|
