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] Re: Streaming XML (WAS: More on taming SAX (was Re:[xml-de

[ Lists Home | Date Index | Thread Index ]

This is unproductive. Miles makes the point that parallel 
ContentHandlers wouldn't be SAX as we know it. You seem to be saying you 
could design a parallel version of SAX that could work, by some 
definition. Since document processing is unlikely to "work" if events 
occur in an arbitrary order on arbitrary threads, I assume you mean 
there would be a mechanism to control which elements could be processed 
in parallel. For the result to be called XML, there would also have to 
be sufficient locking to ensure that PIs arrive in document order wrt 
other events, etc. It's an interesting idea.

Bob Foster

Uche Ogbuji wrote:
> On Fri, 2004-12-31 at 01:31 +0000, Miles Sabin wrote:
>>Uche Ogbuji wrote,
>>>>Cross-platform? Who said anything about cross-platform? What you're
>>>>suggesting would prevent interoperability between parsers on the
>>>>same platform.
>>>You define "platform" however you like.  It's not relevant to the
>>>issue. If I can't invoke a Python ContentHandler from a Java driver
>>>while both are running on the same Fedora Core 3 Linux installation
>>>(does that count as same platform?), why is this a lesser
>>>interoperability failure than the possible inability to run a use a
>>>parallelized driver with an arbitrary ContentHandler?
>>Hmm ... I have to say I'm not at all impressed with this response.
> It's a good thing I wasn't trying to impress you.
>>I'm saying that your creative but broken repurposing of the SAX APIs, 
>>whether in their Java variant or their Python variant, would prevent 
>>interoperability between parsers and ContentHandlers from different 
>>implementors on the same platform _however_ defined.
>>Plug a standard Java ContentHandler into a Java parser with the 
>>semantics you're proposing and it will almost certainly break.
>>Plug a standard Python ContentHandler (or whatever the equivalent is) 
>>into a Python parser with the semantics you're proposing and it will 
>>almost certainly break.
>>This is so blindingly obvious that I can only assume that you're 
>>trolling ...
> I can say the same thing for your own seeming inability to consider what
> I see as the blindingly obvious premise that a SAX implementation that
> was designed for parallelization would of course be primarily suited for
> content handlers that were also designed for parallelization.  Using
> your terminology, you could consider the parallel architecture itself a
> platform, and the fact that parallel and non-parallel don't mix is no
> more extraordinary than the fact that Java and Python implementations do
> not mix.


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

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