[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qexo-general] Namespace rewriting and acces to namespace in consume
From: |
Per Bothner |
Subject: |
Re: [Qexo-general] Namespace rewriting and acces to namespace in consumer |
Date: |
Tue, 07 Jan 2003 12:49:23 -0800 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202 |
address@hidden wrote:
With a xquery request like that :
declare namespace gml = http://www.opengis.net/gml
declare namespace xmlns = http://www.w3.org/XML/1998/namespace
<City xmlns:gml=http://www.opengis.net/gml>
{for $x in document("city1.xml")//Road return $x//gml:name,
for $y in document("city2.xml")//River return $y//gml:name }
</City>
(1) You shouldn't declare namespace xmlns - it's supposed to be
pre-defined.
(2) Qexo currently doesn't handle namespace definitions in
constructed elements. Thus <City xmlns:gml=http://www.opengis.net/gml>
is not handled properly (in XQuery programs - it is handled properly
in XML documents). You have to use 'declare namespace'.
and the result is :
<City xmlns:gml="http://www.opengis.net/gml">
<geo:name>M11</geo:name>
<gml:name>Cam</gml:name>
</City>
The prefix geo is not valid in the result ... Is it possible to rewrite it
into gml ?
(3) Qexo doesn't handle serialization (printing) of namespace prefixes
properly. More generally, it doesn't properly represent namespace
nodes in a document or document fragment, so it just uses whatever
prefix was in the input document. This sometimes works ...
These things will be fixed, but I can't say when. (If I could afford
to work full-time on Qexo, it would of course go faster. So if anyone
needs some Qexo-related consulting, let me know!)
Problem (2) is a local and simple problem that could be fixed by a
volunteer. (An easy "starter" problem!) The tricky aspect is that
a namespace attribute also applies to the element tag and and
any *preceding* attribute. Combined with the fact that an attribute
value may be an arbitrary expression, and it could get ugly. I think
the best solution is to back-patch the attributes and element tag
at the end of the element start, if namespace definitions were seen.
Second, How can i have access to the prefix value in a Consumer ?
When the produces calls the Consumer's beginGroup or beginAttribute
method, the first parameter (typeName or attrName) is the QName is
string form, i.e. "PREFIX:LOCAL". So it is easy to extract the
PREFIX.
Both arguments are stored in the TreeList data structure, so printing
a TreeList will print the same prefixes as the input. This is nice
but a little too simple-minded!
> Do i have to extends the NamespaceResolver class ?
I don't think so.
--
--Per Bothner
address@hidden http://www.bothner.com/per/