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 ]

Gavin, good feedback, thanks.

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

Right.  But I'm only interested in the serialized structure, not
anything to do with activation and binding with that structure (Bento
vs. 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?

That depends.  If any subdocument acts as a container, and the element
of that subdocument which does the containing is required to be
processed (e.g. smil:skip-content="false"), then if a suitable
compound processor cannot be constructed, processing must fail.

As there's no mandatory extension mechanism for XML (like SMIL's
skip-content), a generic processor has to assume that each subdocument
must be processed.  This isn't so bad, but for larger documents it
could mean a delay for any user who'd be using it.

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

It doesn't "ignore" those things.  It says those are orthogonal
issues; the "what" versus the "how".

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

You mean like MS Word? 8-)

I understand what you mean, but I'm not convinced of the value of it.
Anyhow, that's a separate topic.

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

For packaging, I'm assuming a compound document with containment purely
by value.  No XInclude ickiness here (sorry, Dave 8-).

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com


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

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