Mailing-List: contact commons-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3EBAB60F.6030902@apache.org>
Date: Thu, 08 May 2003 12:54:55 -0700
From: Andy Clark <andyc@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3b) Gecko/20030210
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
CC: commons-dev@xml.apache.org, xerces-j-dev@xml.apache.org
Subject: Re: [ANN] XInclude processor for xml-commons
References: <OFB9FF9078.DFEB0D7F-ON85256D1D.007C6200@torolab.ibm.com>
 <3EB72BC7.6090807@apache.org>
In-Reply-To: <3EB72BC7.6090807@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:
>>Well it's turned out to be pretty handy to be able to 
 >>pass "augmentations" along with the events representing
 >>the infoset.
> 
> Can you make an explicit example of this? that would 
 > help us understand better.

In general, the augmentations allow us to extend the
existing framework (in certain ways) within breaking
the method prototypes. But they also have other uses.
For example, in my NekoHTML parser, I use them as a
way of communicating whether elements were specified
in the original document stream or were synthesized
by the tag balancer.

However, the augmentations will most often be used
for passing the PSVI information. And back when we
were debating augmentations, this was the major topic
of discussion. I pushed back from adding XML Schema
related information to XNI in favor of a more generic
system that allowed us to add XML Schema information
as well as any other information we wanted.

>>SAX doesn't have any kind of configuration-management 
 >>infrastructure:  If you want to set up a pipeline of
 >>XMLFilters then you have to manage propagation of
 >>features and properties to the components that comprise
 >>the pipeline on your own;
> 
> Hmmm, I see, but why do you pass such information thru 
 > the pipeline and not as a pipeline context?

When the information is directly associated to the data
being passed through the pipline, then it makes sense to
pass that information via augmentations of that data. In
addition, XNI is designed so that components can alter
the data passed through the pipeline. If an individual
component were to remove information from the pipeline,
it may not be able to understand which associated items
of information to remove if that information is only
passed via a pipeline context.

And it should be noted that we also have the concept
of a pipeline context within XNI. If a component in the
pipeline is interested in the overall settings of the
pipeline, then it can implement XMLComponent. Then,
before the parse it is notified and passed a reference
to the component manager which stores the context. So
it requests just those settings that it understands.

>>SAX is also somewhat impoverished for people who care 
 >>a great deal about the lexical layout of DTD's; there
 >>isn't much you can't get in this respect from XNI.
 >>Although SAX 1.1 extentions (still in alpha!) could
 >>rectify this, as it stands it's not possible to determine
 >>the version or encoding of a document with "stable" SAX
 >>interfaces.
> 
> I see. But the very fact that I, for one, never noticed those
> limitations might seem to advocate against such a move.

Neil is correct when he said that SAX is "impoverished".
And that is one of the major reasons that we made XNI in
the first place -- SAX simply didn't communicate the
information that we needed. Another problem was that
the information was read-only (e.g. Attributes). This
situation may change but at the time we were designing
XNI it was insufficient for our needs.

Also, XNI fulfills a different need than SAX. XNI is
for building different kinds of parsers whereas SAX
is for communicating document information to the app.
XNI could also be used for this purpose but that is
not the primary goal. And we've never marketed XNI
that way.

-- 
Andy Clark * andyc@apache.org