Hi Allen,
Unfortunately Muse is 100% correct in its interpretation of QNames. Its
the same way that XSD, WSDL, XPath etc works. Ie. it relies on a
localname (NCName) with an optional prefix seperated by a colon, where
the prefix is resolved by scope.
Whilst I for one think its a monumentally bad decision as the
{namespace}localName syntax is allways unambiguous and allows
{}localName to specify the "no-namespace namespace" (xmlns="") its non
the less standard behaviour.
I have, for example, added an expression language into Muse (e.g.
subscription filter) to turn this syntax into an XPath of
*[local-name(.) == "localName" and namespace-uri(.) = "namespace"] type
syntax.
cheers,
Chris
-----Original Message-----
From: Allen George [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 01, 2008 4:50 PM
To: [email protected]
Subject: QName serializer issues
Hi,
I've a Muse service that receives an invocation message with a QName
parameter:
<xsd:element name="PrQName" type="xsd:QName"/>
My understanding was that QNames should be converted to text using the
following format:
{namespace}localname
It appears that Muse assumes that QNames have the following text format:
[prefix]:[localpart]
with the namespace being determined from a lookup within the message
xml.
Is this 'correct' behavior?
Thanks,
Allen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
