OK, there is many an occasion where a light-weight data representation
that's not bound by and to an XML Schema is the right choice. (I've
been serialzing data as Perl hashes or, more generally, as Data::Dumper
text, which is similar in spirit to JSON.)
But,as I understand it, JSON is simply a text with a specific syntax, to be
understood by communication peers. So, what's the point in forcing this
format into an XML corset? To embed it in an XML document, I'd send
a JSON text as a single element of type xs:string.
Also, you always have the option to pass XML data through a
(presumably *very* simple) XSLT transformation, to expand or collapse
data as necessary.
Re your "...should be improved?":
Please understand that JAXB is an implementation of the specification
"Java Architecture for XML Binding" (by Sun), and other XML serializers
are based on this, too. Vendor specific extensions aren't good for
interoperability, and changing the spec in any way beyond the limits
of XML Schema is definitely out of scope.
-W
On 18 June 2010 21:31, Leo Romanoff <romixlev_at_yahoo.com> wrote:
>
> Hi Wolfgang,
>
> Thanks a lot for this interesting post!
>
> Here are some comments:
> - Overall, I agree that using XML with an XML Schema is a good style and
> should be used by default, if possible and unless you have really good
> reasons for not doing so.
>
> - But the fact that should not be ignored is that XML is used for almost
> everything nowadays. It became THE common basis format. Almos all modern
> formats are based on it. Many of those do no use schemas at all or do not
> use them properly.
>
> - My original post that started this whole discussion mentioned the wish to
> generate BOTH XML and JSON using the SAME SET of JAXB annotations and to
> produce the SAME structure. Marshalling to XML and to JSON using different
> approaches (e.g. not JAXB based) is easy and not a problem, but requires
> more development time maintenance as you need to keep two implementations in
> sync and support them.
>
> I need JSON because I'd like to use one of those new JSON-based SCHEMA-less
> document-oriented databases like MongoDB and CouchDB. As the name says,
> these DBs are schemaless and are not so strict when it comes to the format
> of data; and they do it for a good reason. I don't want to go into this
> discussion at this place. Anyone is free to read on the Internet about their
> motivation. And these NoSQL DBs are gaining a lot on popularity recently.
>
> I also want to point out that JSON is simpler than XML when it comes to the
> representation of data and usage of schemas. Basically, there is no JSON
> schemas, at least in the same sense as XML schemas relate to XML.
>
> JSON almost always represent maps Map<K,V> by using
> s.th. like
> {
> k1:v1,
> k2:v2
> ...
> }
>
> Most JSON/AJAX tools also assume this representation.
>
> A valid and more schema-friendly XML approach of using <entry
> key="k">v</entry> would not easily work in JSON, as JSON lacks attributes.
> So, what remains is either:
> [{key: k1, value:v1}, {key: k2, value:v2}, ...] {XML-friendly, but very
> unnatural for JSON}
> or
> {k1:v1, k2:v2} (JSON-friendly)
>
> The last JSON-friendly example seems like an adequate solution for me. I
> know that the corresponding XML fragment is not so good from the XML point
> of view, but I can live with that. I know that I loose some nice properties
> that I'd have with a proper XML Schema, but I can live with this. And I
> don't think that one should be forced into using the strict XML Schema based
> approach just because it is considered a good style.
>
> More over, JAXB+JAXWS are just frameworks and tools that should make
> developer's life easier, instead of restricting what can be done. After all,
> XML itself does permit what I want to do. It is JAXB has problems with it.
> So, I'd say: not the problem should be changed or transformed, but may be
> the tool should be improved? Thoughts?
>
> Best,
> Leo
>
>
> Wolfgang Laun-2 wrote:
>>
>> Folks,
>>
>> I have duly noted Aleksei's opinion and Leo's contribution hinting at
>> Maven and POM.
>>
>> It's obvious that XML defines a syntax that can be used freely; but if
>> you want to have a well defined structure (e.g., according to XML
>> Schema) or one that can be conveniently processed with related
>> technologies, you'll have to make amends. I'd like you to note the
>> upshoot of an interesting exchange inspired by this topic I triggered
>> on another list where highly experienced XML-ers contribute. Some
>> replied that <k>v</k> is "possible, but not so good", many preferred
>> <entry key="k">v</entry> or similar; but below is one reply I quote in
>> full.
>>
>> On 18/06/2010 07:28, Wolfgang Laun wrote:
>>
>> Every now and then, people (not me) want to represent a Map<K,V>
>> in XML by using
>> s.th. like
>> <map>
>> <k1>v1</k1>
>> <k2>v2</k2>
>> ...
>> </map>
>> with ki from K and vi from V. Apart from the obvious limitation
>> for K's values,
>> I feel that this is somehow violating the spirit of XML. But this
>> is not a list
>> for XML, and I don't want to risk a red or yellow card.
>>
>> So, more specifically: Doesn't such a "structure" complicate the
>> writing
>> of XSLT constructs? Aren't there any statements or expressions that
>> won't be usable at all? (I don't need an exhaustive list of what isn't
>> possible - I'm more interested in a general judgment.)
>>
>> Michael Kay wrote:
>> I agree: in general it's a poor way of using XML, and it makes it more
>> difficult to process using XSLT.
>>
>> The exception is when the set (k1, k2, k3....) is very predictable and
>> unlikely to change. There's room for debate about this. A schema used
>> in the XMark benchmark uses the names of continents as element names
>> (<Asia>, <Europe>, etc). That feels wrong to me, just as it would feel
>> wrong to use the names of continents as Java variable names. There are
>> many borderline cases: should one use <home-phone>, <work-phone>, and
>> <mobile-phone>, or should one use <phone role="home"> etc? Probably
>> the latter, because it makes it easier to change the set of roles and
>> easier to process all phone numbers in a generic way. But in the end,
>> drawing the line between data and metadata is subjective.
>>
>> The objection about XSLT processing can in principle be overcome if
>> the elements in the set are declared in a schema as having either a
>> common type or as members of a substitution group; doing this gives
>> you a handle in a schema-aware stylesheet to define match patterns
>> that match all elements in the set, or path expressions that select
>> them all. But fixing the set of values in a schema in some ways
>> compounds the error, because it makes it even more difficult to change
>> the value set over time as requirements evolve.
>>
>> SGML old-timers at this point will start reminiscing about
>> architectural forms. I mention this only to point out that it's an
>> issue that has been around for a long time.
>>
>> Best
>> -W
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
>> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Custom-mapping-for-Maps-in-JAXB-tp28779221p28929979.html
> Sent from the java.net - jaxb users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>