From: David Alan Black <dblack@...>
Date: 2002-02-01T22:41:25+09:00
Subject: Re: Ruby + XML Proposal

Hello --

On Fri, 1 Feb 2002, Bryan Murphy wrote:

(lots of interesting stuff deleted)

> Now, you ask, why am I posting this instead of just releasing the
> newest code?  Well, I'm at a bit of a cross-roads.  The REXML stuff
> is a good example.  The next version of the framework will have
> integrated support for cooperating with REXML, but I want to go a
> step further.  I want to not just cooperate with REXML, but *ALL*
> other Ruby XML stuff out there (NQXML, XMLParser, XSLT4R, you name
> it).
>
> There are two ways to accomplish this, the quick easy short term
> method: build the support into the framework.  And the harder but
> more rewarding long term method: build the support directly into the
> corresponding Ruby libraries.

The thing is, you can't predict what XML software people will write in
Ruby in the future.  (Or maybe you're just looking toward things that
are included in the standard distribution?)  If you stake it all on
having every Ruby XML developer support a particular API, there will
always be exceptions.  It might be somewhat more scaleable to stick to
the model of creating a compatibility layer for the engines you want
to support (sort of like DBI).

> An ideal example would be to abstract away the
> REXML(Generator|Serializer) and replace it with a
> Stream(Generator|Serializer).  The stream based components would

You beat me to it :-)  I was going to say: there's too much coupling
between REXML and your layers here.

> work explicitly with the SAX2-like stream of events.  The code that
> generates the stream from a REXML document would then be moved into
> REXML, and the code which generates a REXML document from a stream
> would be moved into REXML as well.  All other libraries could
> implement similar code, and then plug in directly with the Stream
> components in the framework.  Overtime, the actual implementations
> themselves could become less hacky and use real stream based
> implementations for additional speed benefits.  A side effect is
> that you would then be able to connect a REXML stream generator to
> an NQXML document creator and convert a REXML document into an NQXML
> document (and vice versa) as efficiently as possible and in a
> standardized way (or do the same with any other conformant library).
>
> I can provide the initial code for the various XML libraries (and
> will have the starting REXML code ready early next week).  But to
> really do this well, we all need to agree on a streaming model for
> Ruby.  Below is my proposal on what this model should be.  This is
> more or less how my framework is implemented at the moment.  Below
> it is some commentary on why certain things are as they are.  I'd
> like for us to come to an agreement (if at all possible) before I
> get any futher into building the RPF framework, as the more code I
> write, the harder it will be to implement any major changes:

Again, I'm inclined to think that trying to distribute an interface
that isn't the authors' interface across many packages (i.e.,
integrated into those packages) probably won't achieve the consistency
you're looking for, especially since we don't know what the future
will bring.  I can see that SAX may not be everyone's idea of an
appropriate interface for Ruby and other non-Java languages (or even
Java), but I'm not sure that per-programming-language standards in
something like this, where the standard ultimately is external to the
language, is viable.

Or am I just being pessimistic? short-sighted? whatever?

>     def endDocument()

You might want to go with the more Rubily traditional:

  def end_document()

or even

  def end_document

> Finally, if you think all of this is just a load of hot air, I want
> you to think about how you use IO streams.  What do you do if you
> need to get at the contents of a file that are compressed?  You do
> the following:


>   contents = TarArchive.new(File.new('archive.tar.gz')).read()
>   puts contents


> This works because we all agree on what an IO stream is supposed to
> look like.  We can have this same kind of synergy when working with
> XML, we just need to come up with a standard and stick with it ;)

(I didn't know we had a choice about what an IO stream looked like :-)

As you probably know, Maki was working on a Ruby expression of the
SAX2 interface.  I haven't looked at it in a while, and I'm not sure
where it stands, but that might be relevant to you (even if what
you're designing is different).

> Thanks for reading all this!

Thanks for writing it!


David

-- 
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav