Problem (Bug?) with XPath filtering

[Matthes R.-2]

Hello,

I have stumbled across a problem when trying to filter a NotificationMessage
with an XPath expression containing namespace declarations (e.G.
//om:Observation/om:procedure - where om is "http://www.opengis.net/om/1.0
").
Perhaps I made some mistake while subscribing with this filter, but to me it
seems, that the MessagePatternFilter just invokes XPathUtils.isMatch().
isMatch itself invokes XPathAPI.eval(context, xpath) [from apache xalan api]
and that method has no parameter for the namespaceNode. This has the result
that the XPath expression takes its namespaces from the NotificationMessage,
which of course may differ from the ones specified in my subscribe request.

Also I noticed that namespaces in a MessagePatternFilter xml file (see
below) just get erased when parsing the xml with the FilterFactory.

Filter to parse:
<wsnt:Filter xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2">
    <wsnt:MessageContent Dialect="
http://www.w3.org/TR/1999/REC-xpath-19991116"
        xmlns:om="http://www.opengis.net/om/1.0">

//om:Observation/om:procedure/@xlink:href='urn:ogc:object:procedure:CITE:WeatherService:LGA'
    </wsnt:MessageContent>
</wsnt:Filter>


this gets parsed in the subscribe operation of NotificationProducer (I
assume this is done before in the FilterFactory):
<wsnt:Filter xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2">
<wsnt:MessageContent Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116
">//om:Observation/om:procedure/@xlink:href='urn:ogc:object:procedure:CITE:WeatherService:LGA'</wsnt:MessageContent>
</wsnt:Filter>


As you can see the namespace "om:...." is removed.

Did i make a mistake or is there any kind of solution for this problem?

Regards,
Matthes

[Chris.Twiner]

Hi Matthes,

You're entirely correct and did not make a mistake, only the namespaces from the message itself are used.  For my own needs I have extended the xpath syntax (new dialect) to use full qnames instead so:

//{http://www.opengis.net/om/1.0}:Observation/{http://www.opengis.net/om/1.0}:procedure/@xlink:href='urn:ogc:object:procedure:CITE:WeatherService:LGA'

becomes

//*[namespace-uri="http://www.opengis.net/om/1.0" and local-name="Observation"]/...

but this decision was also driven from a tooling perspective.  Obviously its not helpful and I think the standard Muse behaviour is confusing.

Logically we should pass in what the prefixes map to and not just hope they are the same as used on the NotificationMessage.

Please raise this as an issue on jira, I may even be able to get a patch ready for it today.

cheers,
Chris

-----Original Message-----
From: Matthes R. [mailto:m.rieke.mailing@...]
Sent: Saturday, August 30, 2008 1:40 PM
To: muse-user@...
Subject: Problem (Bug?) with XPath filtering

Hello,

I have stumbled across a problem when trying to filter a NotificationMessage with an XPath expression containing namespace declarations (e.G.
//om:Observation/om:procedure - where om is "http://www.opengis.net/om/1.0 ").
Perhaps I made some mistake while subscribing with this filter, but to me it seems, that the MessagePatternFilter just invokes XPathUtils.isMatch().
isMatch itself invokes XPathAPI.eval(context, xpath) [from apache xalan api] and that method has no parameter for the namespaceNode. This has the result that the XPath expression takes its namespaces from the NotificationMessage, which of course may differ from the ones specified in my subscribe request.

Also I noticed that namespaces in a MessagePatternFilter xml file (see
below) just get erased when parsing the xml with the FilterFactory.

Filter to parse:
<wsnt:Filter xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2">
    <wsnt:MessageContent Dialect="
http://www.w3.org/TR/1999/REC-xpath-19991116"
        xmlns:om="http://www.opengis.net/om/1.0">

//om:Observation/om:procedure/@xlink:href='urn:ogc:object:procedure:CITE:WeatherService:LGA'
    </wsnt:MessageContent>
</wsnt:Filter>


this gets parsed in the subscribe operation of NotificationProducer (I assume this is done before in the FilterFactory):
<wsnt:Filter xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2">
<wsnt:MessageContent Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116
">//om:Observation/om:procedure/@xlink:href='urn:ogc:object:procedure:CITE:WeatherService:LGA'</wsnt:MessageContent>
</wsnt:Filter>


As you can see the namespace "om:...." is removed.

Did i make a mistake or is there any kind of solution for this problem?

Regards,
Matthes

---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...

[Matthes R.-2]

Hi Chris,

thanks for your reply. I have created an issue for this:
https://issues.apache.org/jira/browse/MUSE-293

regards,
Matthes


2008/9/3 <Chris.Twiner@...>

> Hi Matthes,
>
> You're entirely correct and did not make a mistake, only the namespaces
> from the message itself are used.  For my own needs I have extended the
> xpath syntax (new dialect) to use full qnames instead so:
>
> //{
> http://www.opengis.net/om/1.0}:Observation/{http://www.opengis.net/om/1.0}:procedure/@xlink:href='urn:ogc:object:procedure:CITE:WeatherService:LGA<http://www.opengis.net/om/1.0%7D:Observation/%7Bhttp://www.opengis.net/om/1.0%7D:procedure/@xlink:href=%27urn:ogc:object:procedure:CITE:WeatherService:LGA>
> '
>
> becomes
>
> //*[namespace-uri="http://www.opengis.net/om/1.0" and
> local-name="Observation"]/...
>
> but this decision was also driven from a tooling perspective.  Obviously
> its not helpful and I think the standard Muse behaviour is confusing.
>
> Logically we should pass in what the prefixes map to and not just hope they
> are the same as used on the NotificationMessage.
>
> Please raise this as an issue on jira, I may even be able to get a patch
> ready for it today.
>
> cheers,
> Chris
>
> -----Original Message-----
> From: Matthes R. [mailto:m.rieke.mailing@...]
> Sent: Saturday, August 30, 2008 1:40 PM
> To: muse-user@...
> Subject: Problem (Bug?) with XPath filtering
>
> Hello,
>
> I have stumbled across a problem when trying to filter a
> NotificationMessage with an XPath expression containing namespace
> declarations (e.G.
> //om:Observation/om:procedure - where om is "http://www.opengis.net/om/1.0").
> Perhaps I made some mistake while subscribing with this filter, but to me
> it seems, that the MessagePatternFilter just invokes XPathUtils.isMatch().
> isMatch itself invokes XPathAPI.eval(context, xpath) [from apache xalan
> api] and that method has no parameter for the namespaceNode. This has the
> result that the XPath expression takes its namespaces from the
> NotificationMessage, which of course may differ from the ones specified in
> my subscribe request.
>
> Also I noticed that namespaces in a MessagePatternFilter xml file (see
> below) just get erased when parsing the xml with the FilterFactory.
>
> Filter to parse:
> <wsnt:Filter xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2">
>    <wsnt:MessageContent Dialect="
> http://www.w3.org/TR/1999/REC-xpath-19991116"
>        xmlns:om="http://www.opengis.net/om/1.0">
>
>
> //om:Observation/om:procedure/@xlink:href='urn:ogc:object:procedure:CITE:WeatherService:LGA'
>    </wsnt:MessageContent>
> </wsnt:Filter>
>
>
> this gets parsed in the subscribe operation of NotificationProducer (I
> assume this is done before in the FilterFactory):
> <wsnt:Filter xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2">
> <wsnt:MessageContent Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116
>
> ">//om:Observation/om:procedure/@xlink:href='urn:ogc:object:procedure:CITE:WeatherService:LGA'</wsnt:MessageContent>
> </wsnt:Filter>
>
>
> As you can see the namespace "om:...." is removed.
>
> Did i make a mistake or is there any kind of solution for this problem?
>
> Regards,
> Matthes
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@...
> For additional commands, e-mail: muse-user-help@...
>
>

[Chris.Twiner]

Hi Matthes,

I'm replying directly as its not something that should be generally suggested.  If you are running in an environment that allows you to control the classpath (.war's can use the WEB-INF/classes directory for this) you could seperate out the functionality from the unit test I attached to 293, and use the code directly.

Either way it would be great if you could run the test (just needs muse and junit on the path) and see if everything works the way you'd expect it.

Nothing in the public interfaces from the MessagePattern handling have changed so this should *work*.

cheers,
Chris

-----Original Message-----
From: Matthes R. [mailto:m.rieke.mailing@...]
Sent: Wednesday, September 03, 2008 6:27 PM
To: muse-user@...
Subject: Re: Problem (Bug?) with XPath filtering

Hi Chris,

thanks for your reply. I have created an issue for this:
https://issues.apache.org/jira/browse/MUSE-293

regards,
Matthes


2008/9/3 <Chris.Twiner@...>

> Hi Matthes,
>
> You're entirely correct and did not make a mistake, only the
> namespaces from the message itself are used.  For my own needs I have
> extended the xpath syntax (new dialect) to use full qnames instead so:
>
> //{
> http://www.opengis.net/om/1.0}:Observation/{http://www.opengis.net/om/
> 1.0}:procedure/@xlink:href='urn:ogc:object:procedure:CITE:WeatherServi
> ce:LGA<http://www.opengis.net/om/1.0%7D:Observation/%7Bhttp://www.open
> gis.net/om/1.0%7D:procedure/@xlink:href=%27urn:ogc:object:procedure:CI
> TE:WeatherService:LGA>
> '
>
> becomes
>
> //*[namespace-uri="http://www.opengis.net/om/1.0" and
> local-name="Observation"]/...
>
> but this decision was also driven from a tooling perspective.
> Obviously its not helpful and I think the standard Muse behaviour is confusing.
>
> Logically we should pass in what the prefixes map to and not just hope
> they are the same as used on the NotificationMessage.
>
> Please raise this as an issue on jira, I may even be able to get a
> patch ready for it today.
>
> cheers,
> Chris
>
> -----Original Message-----
> From: Matthes R. [mailto:m.rieke.mailing@...]
> Sent: Saturday, August 30, 2008 1:40 PM
> To: muse-user@...
> Subject: Problem (Bug?) with XPath filtering
>
> Hello,
>
> I have stumbled across a problem when trying to filter a
> NotificationMessage with an XPath expression containing namespace
> declarations (e.G.
> //om:Observation/om:procedure - where om is "http://www.opengis.net/om/1.0").
> Perhaps I made some mistake while subscribing with this filter, but to
> me it seems, that the MessagePatternFilter just invokes XPathUtils.isMatch().
> isMatch itself invokes XPathAPI.eval(context, xpath) [from apache
> xalan api] and that method has no parameter for the namespaceNode.
> This has the result that the XPath expression takes its namespaces
> from the NotificationMessage, which of course may differ from the ones
> specified in my subscribe request.
>
> Also I noticed that namespaces in a MessagePatternFilter xml file (see
> below) just get erased when parsing the xml with the FilterFactory.
>
> Filter to parse:
> <wsnt:Filter xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2">
>    <wsnt:MessageContent Dialect="
> http://www.w3.org/TR/1999/REC-xpath-19991116"
>        xmlns:om="http://www.opengis.net/om/1.0">
>
>
> //om:Observation/om:procedure/@xlink:href='urn:ogc:object:procedure:CITE:WeatherService:LGA'
>    </wsnt:MessageContent>
> </wsnt:Filter>
>
>
> this gets parsed in the subscribe operation of NotificationProducer (I
> assume this is done before in the FilterFactory):
> <wsnt:Filter xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2">
> <wsnt:MessageContent
> Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116
>
> ">//om:Observation/om:procedure/@xlink:href='urn:ogc:object:procedure:
> CITE:WeatherService:LGA'</wsnt:MessageContent>
> </wsnt:Filter>
>
>
> As you can see the namespace "om:...." is removed.
>
> Did i make a mistake or is there any kind of solution for this problem?
>
> Regards,
> Matthes
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@...
> For additional commands, e-mail: muse-user-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...