Bug #1306
jibx not deserializing gmn-serialized objects
100%
Description
the xml returned from gmn is different from that returned from metacat:
For example, the same response from a create on both returns an Identifier, but slightly different:
Metacat:
<?xml version="1.0" encoding="UTF-8"?>simpleApiTests:testid:201139103132824/d1:identifier
GMN:
<?xml version="1.0" ?>simpleApiTests:testid:20113910324674/ns1:Identifier
differences:
1. GMN does not return the encoding (UTF-8)
2. "ns1:Identifier" for gmn, "d1:identifier" for metacat
Not sure where the solution lies.
History
#1 Updated by Rob Nahf about 13 years ago
- Category set to d1_common_java
- Priority changed from Normal to High
#2 Updated by Matthew Jones about 13 years ago
Both of those formats appear valid to me. The encoding is optional in XML, and defaults to UTF-8 if it is not specified in the prolog or in the transport headers. So, our parsers should be able to handle that without issue, and we should expect multiple implementations that use different encodings, or that leave encoding to the default.
The namespace prefix is also fine -- implementations are always free in XML to use any prefix they want, as long as they map their prefix to the correct namespace. The XML parsers should handle this seamlessly, so again it should not be an issue. We should accept any prefix for a namespace, and it would be a serious flaw if we tried to force a hardcoded prefix.
#3 Updated by Dave Vieglais about 13 years ago
the second issue described here is actually an issue - the "Identifier" should be "identifier"
#4 Updated by Roger Dahl about 13 years ago
- Target version changed from Sprint-2011.05 to Sprint-2011.06
- Assignee set to Roger Dahl
- Status changed from New to Closed
- Category changed from d1_common_java to d1_mn_GMN
(1) Not an error.
(2) Fixed.
