RE: [xml-dev] The general XML processing problem

["Manos Batsis" <m.batsis@bsnet.gr>]

> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com] 

> As long as no one insists that it is the "intent" of XML
> to separate presentation and content, that's a pertinent 
> topic.  It's just a smart thing to use XML to do.

Absolutely. XML was build so that people can think of smart things to do
with it.


> My problem with pipelines, particularly ones that use transformation, 
> is that someone has to sit down and solve the "gossip chain" 
> problem. 
> That is, small semantic errors that creep into 
> the maps.  As much as we may say XML is devoid of intent, 
> a chained process isn't.

Many of the problems can be solved in less demanding ways than pipelines
(although those are extremely useful). For example, I would have far
less late nights of coding if I could control entity expansion or add a
namespace to a node in a transformation process (talking about XSLT as
an example). The need for a pipeline is usually created due to inability
of performing something in one stage only.


> That is why so much is made of 
> strong semantic types; send this; return that.  Know a priori 
> what this and that are.   Functional, yes, but entirely 
> practical.

Absolutely. But typing in it's OO sense is not the complete answer to
XML problems. Inconsistent, incomplete APIs and luck of control is part
of the problem IMHO. Hiding XML behind classes may be a strong
convenience but current problems are much simpler and directly related
to control over the Infoset.

What worries me even more is that the "progress" in the form of new
drafts does not deal with such issues as much as I would like them too;
instead I see more and more energy behind the OO features related to XML
Schema, like someone took over XML development or something and pushes
everything under the new rag.

Cheers,

Manos