Robert Koberg wrote:
Well, the XML DB vendors pitch the XML DB as a web application
platform. There is also the XRX push from some who push this as
well. As soon as you get your first request parameter (or
import your vendor's request namespace) you are into vendor
defined extensions.
Thanks for clarification. Yes, you're right. That's because
there is room for something that has not been standardized as
part of the language (and really, I think that's good, that would
have been premature standardization.) Ans that's good that
vendors try to fill the gap by providing their users with a way
to achieve what they want, even if it is by mean of extensions.
In that particular example (get HTTP request params) I think
that's good that has not been defined in XQuery itself. I see
two (non-exclusive) options: 1/ define a set of extensions to
provide those features, as a spec (like a JSR,) hoping vendors
will implement it or 2/ create a tool, a framework, implemented
for several processors, that provides those features (so you have
to maintain it on several processors, and several versions of
them.)
I think that a lot of people would like to be able to use such
an API. If you have any particular ideas about such a framework,
please share them on the EXQuery open mailing list available at
<http://www.exquery.org/mailing-lists.xml>.
This happens almost right away. It seems to me that the XQuery
standard is a hook for the user that is tossed aside as soon as
they are on the line.
Well, XQuery (or XSLT) is not tossed aside as soon as you use
any one extension. The developer has to design her code to be
easily migrated to another processor (after having evaluated the
benefit of using the extension.) But that's still XQuery.
Whatever the vendor's samples are, how often they use
vendor's extensions, that remains the responsibility of the
developer to know what is an extension and what is standard,
and use wisely this distinction.
Of course, but we are talking about a W3 standard. I can run
HTML on any browser,
Funny you take HTML as an example of good interoperability, I
would rather use it the other way around ;-)
parse XML with any XML parser, run XSL on any XSL processor
(and there is a mechanism to check for vendor extensions and
choose the correct one based on the processor)
Well, I wouldn't say the situation is much different between
XSLT and XQuery. Of course, XSLT has use-when. But if you are
talking about web applications to be able to be installed on
several processors, you can always use a setup process to install
the correct vendor-specific library module that encapsulates the
vendor-specific extensions.
However, it seems to have a demand about such a feature. If
you have any idea about that subject, please share them on the
EXPath mailing list <http://www.expath.org/lists.html>. There
was a thread on the subject last week:
http://groups.google.com/group/expath/browse_frm/thread/141ed36fe5733031/0b317f5319977f70
Also, the vendor specific ones are usually better performing
than there standard alternative.
Could be, yes. And that could be a legitimate reason to use an
extension. But there is no algorithm that will give you a yes/no
answer.
I guess that's the "database-world syndrome." I've rarely
met a DBA who tries to make her SQL code as portable as
possible, and who cares about (over)using vendor-specific
extensions.
I am not a DBA, but I use Hibernate to keep the (generated) SQL
vendor agnostic. But again, XQuery is a W3 standard.
And SQL an ISO standard. This is difficult to set the scope of
a language being specified, as it is actually used outside, and
when vendors urge to get a standard. But I think XQuery has a
consistent scope, even if maybe an official optional REC or NOTES
about an XML-DB admin functions would help interoperability. But
that's not the job of XQuery itself I think.
I just can't help feeling there is a con going on. That is
probably too strong, but I hear, "Look at my standards
compliant XML DB - you can use standards based XQuery. However,
to use it as we suggest, you will need to use our extensions."
Why not? "If you want to use it behind the XQuery REC, you
have to use extensions." Yes, why not?
Say the path/to/col contains the documents 1.xml, 2.xml and
3.xml cross XQuery processor, what does a
collection('path/to/col')/* provide?
Once you will have defined what exactly means "path/to/col
contains the documents 1.xml, 2.xml and 3.xml" on several
processors, you will get the response.
I think you have to get the problem the other way around: "I
have defined my application to use the collection mechanism
to organize my documents, how can I setup this processor to
get the correct documents when I access this or that
collection?"
I don't understand the point you are making here.
The point is: what does mean the first part of you sentence
("the path/to/col contains the documents [...]") ?
I think EXQuery <http://www.exquery.org/> will play an
important role in that regard.
Yes and thanks for taking the lead on this.
To be honest, Adam has the lead on EXQuery (but we told about
EXPath <http://www.expath.org/> stuff also :-p.)
PS: Wonder if we shouldn't switch to XQuery Talk or EXQuery...?
Regards,
--
Florent Georges
http://www.fgeorges.org/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--