incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amelia A Lewis <>
Subject Re: [PROPOSAL] gXML project
Date Wed, 14 Jul 2010 21:12:47 GMT
Dear Jochen,

Thanks for the pointer to VxQuery.  Actually, I think that that project 
might benefit from adopting gXML.

VxQuery appears to be what gXML would deem a processor.  gXML 
effectively provides an infrastructure that could simplify things for 
VxQuery (and similar projects that target multiple tree models).  
VxQuery appears to be using a classic wrapper/facade pattern to achieve 
tree model independence.  The problem with doing this is that it's 
expensive; the larger the tree, the higher the cost in wrapper objects.

gXML doesn't provide an XQuery processor.  What it provides is an API 
that reflects the XQuery Data Model (XDM) using Java generics and the 
Handle/Body pattern.  That is, rather than wrapping each node, a 
"bridge" (the gXML term for a tree model adapter) provides a single 
Model, which can perform XDM-mandated actions (information about a 
node, movement from a source node to a particular 
algorithmically-defined destination (first child, next sibling, etc.), 
iteration over axes) without creating additional objects.  (I'm trying 
not to be too detailed/technical; I can be if that's more useful)

There's some nice potential for enabling each other's projects, I 
think.  :-)  We'll need to contact the VxQuery folks.  Well, there are 
a bunch of folks we'd like to contact ....  But VxQuery really looks 
like a classic case where our bridges would potentially be of deep 
interest to the project, with the possibility of reducing LoC count and 
improving performance.

For the initial code contribution, gXML contains three bridges: DOM, 
AxiOM, and a "reference" bridge designed for simplicity (but not at all 
for performance; it's just supposed to be a *very large* example of 
bridge development, in effect, without the complexities entailed by 
programming to existing tree models).  The ability to define these 
bridges over tree models (and potentially, over any hierarchical data 
model) is one of gXML's most powerful contributions, I think.

Hmmmm ... is that a useful response?  Let us know, okay?  I tend to 
verbosity ....

On Wed, 14 Jul 2010 21:40:20 +0200, Jochen Wiedmann wrote:
> I am interested in the project and would offer to act as a mentor.
> One question though: Could you explain, how this project compares to
> VXQuery (
> Thanks,
> Jochen
> On Wed, Jul 14, 2010 at 7:42 PM, Eric Johnson <> wrote:
>> Hi,
>> I'm here proposing gXML as a new project for the Apache Incubator.
>> I just finished putting our latest draft of the proposal[1] into the
>> Incubator wiki.  We're really excited about open-sourcing gXML, not just
>> because we view it as a "game changing" XML technology, but also because
>> of the beneficial network effects stemming from having it as an
>> open-source technology.
>> If you have any interest in (Java) XML infrastructure, or, for that
>> matter, even if you don't, we'd love any feedback you can give us on the
>> proposal.
>> Since this is a spin off of an internal development project, we're
>> hosting the project's main page [2] on my company's web site until it
>> lands in a new home....  Check that out for source and other info, if
>> you wish.
>> We are, in addition, looking for Champions, Mentors, and any additional
>> contributors that we can get.
>> Due to the length of the proposal (lots of background material), I've
>> not reproduced it here, but the link below will get you there.
>> Thanks in advance for your consideration, feedback, and support!
>> - Eric Johnson
>> [1]
>> [2]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> -- 
> Germanys national anthem is the most boring in the world - how telling!
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message