Re: [Qexo-general] Namespace rewriting and acces to namespace in consumer

[Per Bothner]

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/