Tom Bradford wrote:
>
> On Tuesday, January 8, 2002, at 06:54 PM, Kimbro Staken wrote:
> > Would that achieve the exact same thing though? My goal was to be able
> > to prewire certain relationships so that queries could be simplified
> > and maybe even be sped up by removing the join. It won't work for all
> > applications, but for some if could be very handy. It also gets more
> > mileage out of straight XPath queries.
>
> It would produce the same result, because you could use the same
> namespaced link attributes, but it would require the document to be
> processed manually instead of automagically, allowing the linking
> functionality to not be tied specifically to our DOM implementation. A
> single XQuery query could be used to perform the linking, and it could
> even be done using SAX or DOM (where right now, we can only do it using
> DOM).
>
> >> What I ultimately really want is to have our DOM implementation
> >> function identically to any other DOM you could bootstrap using JAXP,
> >
> > This sounds like a nice goal, but is it really necessary? What does it
> > gain us and what do we lose? I'm just trying to understand the
> > motivation.
>
> For the client/server model, probably not much, but if you were to embed
> the server into another application (say Tomcat, for example), there may
> be conflicts as to which DOM is used. Either we can explicitly create
> our own DOM instances ignoring the DOMBuilder stuff, or we can work
> cleanly with JAXP, which has the benefit of not requiring
> inter-implementation conversion, which may slow things down if nodes are
> imported between DOMs.
You're right pointing out that there is some impedence mismatch between
an application *using* XML and a database storage solution (say Tomcat
and XIndice).
But I this is a *feature* not a bug.
I mean: if you wrap XIndice with a JAXP layer, you allow Tomcat to use
XIndice as 'XML parser' and you could use it instead of a file system
(which might be incredibly useful for clusters of tomcats all using the
same configuration served from an XML db!)
I don't question the fuctionality, but I question the softare
architecture.
In my vision, the impedence mismatch percevied is a sign of the need for
another layer between the two. Something that *uses* XIndice as an
engine but provides all those 'file-system-like' functionalities that
people would need anyway.
For example, providing a webdav interface might allow to make this
tomcat-cluster happy, with no need to have a direct JAXP implementation
(also JAXP would require you to use RMI for distributed applications,
while soap or webdav would do it over the wire).
Anyway, besides the implementation details and the examples, my point
is: let's XIndice focus on the engine. The applications will come.
> >> and offload functionality like AutoLink into another layer, preferably
> >> into an XQuery engine, where the behavior is easily coded, instead of
> >> using Java to do it.
> >
> > I think you need to explain more what you mean here. I'm not seeing the
> > benefit of pushing it into the XQuery layer or even how it would work.
>
> <above/>
>
> >> Personally, I don't like XQuery, and would prefer it we XUpdate and
> >> XSelect were the standards, but I'm not the one who influences the XML
> >> world :-)
> >>
> >
> > Ugh, while XQuery isn't great I'd much rather have that then a
> > cumbersome XML syntax language. XUpdate is nice but, I always find it
> > very, very cumbersome to use. I want better interactive query and
> > update facilities and I just don't see XUpdate and XSelect getting us
> > there. XQuery may not be the right way either, but it is a lot closer.
>
> Closer? Like XQuery updates? :-) I'm not holding my breath.
There is no agreement in the XML world about what "xml updates" mean or
should do. If there is no agreement between you and Kimbro, go figure
into the rest of the XML world.
And I *like* the fact that the W3C doesn't recommend something they
can't focus on (besides XMLSchema, that is).
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
