QName serializer issues
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
QName serializer issues
by allen_a_george
::
Rate this Message:
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: muse-user-unsubscribe@... For additional commands, e-mail: muse-user-help@... |
|
|
RE: QName serializer issues
by Chris.Twiner
::
Rate this Message:
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:allen.george@...] Sent: Thursday, May 01, 2008 4:50 PM To: muse-user@... 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: 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@... |
|
|
Re: QName serializer issues
by allen_a_george
::
Rate this Message:
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 Chris.Twiner@... 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:allen.george@...] > Sent: Thursday, May 01, 2008 4:50 PM > To: muse-user@... > 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: 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@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: muse-user-unsubscribe@... For additional commands, e-mail: muse-user-help@... |
|
|
RE: QName serializer issues
by Chris.Twiner
::
Rate this Message:
Hi Allen,
glad I could help, Chris -----Original Message----- From: Allen George [mailto:allen.george@...] Sent: Monday, May 05, 2008 9:13 PM To: muse-user@... 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 Chris.Twiner@... 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:allen.george@...] > Sent: Thursday, May 01, 2008 4:50 PM > To: muse-user@... > 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: 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@... > > --------------------------------------------------------------------- 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@... |
| Free embeddable forum powered by Nabble | Forum Help |
