[bdbxml] input/output event API proposal

[George Feinberg]

All,

I've been talking about this for a while. We're proposing some new
API to allow better integration of XML tools and applications
with BDB XML. We've got a rough cut, and would like some
community feedback while there's time to fine-tune it.

The details can be found at
http://dev.sleepycat.com/bdb-xml-event-api-review

Comments and discussion -- positive and negative -- are highly
encouraged! The overview is on the web page, but here are a
couple of points to remember when looking at it:

o "event" means input/output streaming events, not "notification"
or anything to do with asynchronous "events."

o it does not try match any existing standard API precisely. It's
designed to enable mapping to/from various standard APIs, where
that mapping is provided by an application, or contributed
for a given tool/language combination

o BDB XML supports a number of language interfaces, so it's
designed to handle that (e.g. it does not rely on virtual behavior)

o Look at it through the lens of your own favorite toolset and
programming language, and be sure that it fits your model.
If not, we want to know!

Thanks!

George




------------------------------------------
To remove yourself from this list, send an
email to xml-unsubscribe-***@public.gmane.org

[John Merrells]

Oh that's nice :)

John

Post by George Feinberg
All,
I've been talking about this for a while. We're proposing some new
API to allow better integration of XML tools and applications
with BDB XML. We've got a rough cut, and would like some
community feedback while there's time to fine-tune it.
The details can be found at
http://dev.sleepycat.com/bdb-xml-event-api-review
Comments and discussion -- positive and negative -- are highly
encouraged! The overview is on the web page, but here are a
o "event" means input/output streaming events, not "notification"
or anything to do with asynchronous "events."
o it does not try match any existing standard API precisely. It's
designed to enable mapping to/from various standard APIs, where
that mapping is provided by an application, or contributed
for a given tool/language combination
o BDB XML supports a number of language interfaces, so it's
designed to handle that (e.g. it does not rely on virtual behavior)
o Look at it through the lens of your own favorite toolset and
programming language, and be sure that it fits your model.
If not, we want to know!
Thanks!
George
------------------------------------------
To remove yourself from this list, send an

------------------------------------------
To remove yourself from this list, send an
email to xml-unsubscribe-***@public.gmane.org

[Jacoby Thwaites]

I would agree that for a library like DB XML it's more important to
have something very close to the native workings than to provide
standard interfaces (as you mention).

My main concern about getting docs/elements as strings, then re-
parsing them into someplace else is performance and efficiency (and
elegance, I suppose), scalability being the prime concern. So being
close to native dbxml really knocks that concern on the head.

Also, pull interface for reading is more efficient than a SAX-style
push, at this lower level.

That having been said, where I'd first like to use this is as a SAX
source & sink for Michael Kay's XSLT 2.0 product (which is a real
work of art, I take it EVERYONE is using it!). So for Java it's
really a question of producing a SAX converter, which for the basic
case looks pretty simple from what you've documented.

Jacoby



------------------------------------------
To remove yourself from this list, send an
email to xml-unsubscribe-***@public.gmane.org

[George Feinberg]

Jacoby,

Thanks for the feedback.

Here's another question that is Java-specific.
At this time, the Java versions of these classes use
String as parameters and return values for all of the
methods. Should all, or some of these use byte[] instead?

Given the tools/application integration that BDB XML Java
users have, which makes more sense? One or the other,
or a combination (e.g. String for names, but byte[] for
(potentially large) text values)?

Internally, the strings are C++ const unsigned char (UTF-8),
so *some* conversion will happen at the Java interface, and
byte[] may be more efficient, if that matters.

Regards,

George

Post by Jacoby Thwaites
I would agree that for a library like DB XML it's more important to
have something very close to the native workings than to provide
standard interfaces (as you mention).
My main concern about getting docs/elements as strings, then re-
parsing them into someplace else is performance and efficiency (and
elegance, I suppose), scalability being the prime concern. So being
close to native dbxml really knocks that concern on the head.
Also, pull interface for reading is more efficient than a SAX-style
push, at this lower level.
That having been said, where I'd first like to use this is as a SAX
source & sink for Michael Kay's XSLT 2.0 product (which is a real
work of art, I take it EVERYONE is using it!). So for Java it's
really a question of producing a SAX converter, which for the basic
case looks pretty simple from what you've documented.
Jacoby
------------------------------------------
To remove yourself from this list, send an

------------------------------------------
To remove yourself from this list, send an
email to xml-unsubscribe-***@public.gmane.org

[John Ralls]

Post by George Feinberg
All,
I've been talking about this for a while. We're proposing some new
API to allow better integration of XML tools and applications
with BDB XML. We've got a rough cut, and would like some
community feedback while there's time to fine-tune it.

This looks great for SAX-oriented document handling.

Are there any (more) changes planned for the (set|get)ContentAsDOM
interfaces? (I just browsed through Document.cpp in 2.2.13 for the
first time and I see that it has changed a lot since 2.1, which was
the last version I had dug into. I'm wondering how much effort I
should expend on understanding what's going on there. Probably not
much if 2.3 is going to be really different.) For example, is DOM
still going to be tied to Xerces-c, or will the user be able to build
against any DOM library, and therefore pass in and retrieve
DOMDocuments and DOMNodes for that library?


Regards,
John Ralls


------------------------------------------
To remove yourself from this list, send an
email to xml-unsubscribe-***@public.gmane.org

[John Snelson]

Post by John Ralls
Are there any (more) changes planned for the (set|get)ContentAsDOM
interfaces? (I just browsed through Document.cpp in 2.2.13 for the
first time and I see that it has changed a lot since 2.1, which was the
last version I had dug into. I'm wondering how much effort I should
expend on understanding what's going on there. Probably not much if 2.3
is going to be really different.) For example, is DOM still going to be
tied to Xerces-c, or will the user be able to build against any DOM
library, and therefore pass in and retrieve DOMDocuments and DOMNodes
for that library?

This is certainly something we have been thinking about. No changes are
planned here for the next release, however the Xerces-C DOM really
exposes a little too much implementation detail, and as we move the
product forward could become a compatibility bind. If this changes, it
would be to a DOM like interface that we could then export for all our
language bindings.

John
--
John Snelson, Berkeley DB XML Engineer
Sleepycat Software, Inc
http://www.sleepycat.com

Contracted to Sleepycat through Parthenon Computing Ltd
http://blog.parthcomp.com/dbxml


------------------------------------------
To remove yourself from this list, send an
email to xml-unsubscribe-***@public.gmane.org