Hi Allen, glad I could help,
Chris -----Original Message----- From: Allen George [mailto:[EMAIL PROTECTED] Sent: Monday, May 05, 2008 9:13 PM To: [email protected] Subject: Re: QName serializer issues Hi Chris, I didn't realize this - I really appreciate your explanation of what's happening. Since I've control over both ends of the implementation I will change my service to serialize the QName in the standard way... Thanks, Allen [EMAIL PROTECTED] wrote: > 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] > > --------------------------------------------------------------------- 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]
