Hi Charles,
A helpful message on the java client-side (qnames without prefix not supported, register a namespace + prefix first, etc) would be great already, but I would think that supporting Clark notation on REST server side shouldn’t be too difficult. So if it could be supported, that would be great. Kind regards, Geert *Van:* [email protected] [mailto: [email protected]] *Namens *Charles Greer *Verzonden:* maandag 29 oktober 2012 17:44 *Aan:* MarkLogic Developer Discussion *Onderwerp:* Re: [MarkLogic Dev General] REST api keyvalue call with QName Hi Geert, this is a known issue with the Java API. What's going on is that QName.toString() serializes two different ways. If there's no prefix defined for the given Namespace URI, toString() yields a Clark notation string. If there is a prefix, it yields prefix:local-name. The REST API only supports the latter. So you need to define a prefix for your namespace in this case and things will just work. We're planning the next version now, is Clark notation something you'd like to see supported in this situation? Charles On Mon, Oct 29, 2012 at 7:56 AM, Geert Josten <[email protected]> wrote: Hi, We are exploring the REST api, and tried using the keyvalue endpoint from Java. We created an ElementLocator, and passed in a QName object created with the (namespace uri, localname) constructor. This results in a call in which the element param value is encoded as {namespaceuri}localname. The REST endpoint seems to choke on this. I'd expected either the Java to throw an exception, or the HTTP endpoint to accept this syntax. But instead an exception is returned that the element param value cannot be casted to QName. I'm guess the /config/namespaces endpoint provides a way round, but like to hear some comments on this. Anyone? Kind regards, Geert M.Sc. G.P.H. (Geert) Josten Senior Developer Dayon B.V. Delftechpark 37b 2628 XJ Delft The Netherlands T +31 (0)88 26 82 570 [email protected] www.dayon.nl De informatie - verzonden in of met dit e-mailbericht - is afkomstig van Dayon BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend. _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
