correction: "keeping the data small in transit if plain text is needed"...
Post by k***@u.washington.eduIt sounds like decisions for that use of XML were made with SGML goals
rather than data as part of a typed object (without behavior). Interesting
stuff.
I still think any JSON you see on the server side is most likely due to a
chain of use cases that may have roots in working around thin client rules
regarding same origin policy and also keeping the data small on the client
side.
consistent choices in the primary reasons for choosing a data
encapsulation hopefully don't require wrappers that defeat the original
goals, but bridges between technologies are sometimes necessary, but that's
a different use case.
Back in the 20th century, I worked on the Open Travel Alliance (OTA)<http://www.opentravel.org/> XML
standards committee, and was a major contributor to version 1 (to the point
that my children's names are in the document's example XML).
At this point I learned the distinction between the MOM and POP camps of
the XML community: MOM - Message oriented Middleware; POP - Presentation
oriented Publishing.
The MOM camp wanted XML to be simple and and POP camp wanted XML to be
powerful and flexible. From a MOM camp members perspective, the problem
with XML is that the POP camp WON!
In any case, in the OTA's architecture committee, there was a large debate
about the value of using validating XML parsers (w/ XML Schema just coming
While XML Schemas are incredibly valuable from a specification
perspective, they are almost worthless from a validation perspective!
Schema validation only guarantees Syntax, and does next to nothing for
Semantics - In the MOM world (which was what the OTA was about) Semantics
are what matters!
Since the schema reference is carried in the XML, and it is this Schema
applied by the parser (as opposed to being provided to the parser by the
receiving code), it can't be trusted - if you can't trust the sender to
send appropriate XML, you can't trust the Schema reference in the XML!
IMO, the built in nature of SON on the browser, and the POP camp; has
driven the Web Services "standard" away from XML, and toward JSON.
George
Hi David,
I guess that would be one way. We're already using JAX-RS and defining
our interface objects in XSD to generate the classes, so we're most of the
way there. It is kind of a roundabout way to go though.
Dan
------------------------------
*Sent: *Wednesday, November 13, 2013 8:14:24 AM
*Subject: *Re: [seajug] JSON Schema
If the goal is to have self-describing schema, and to also use JSON,
Use a JAX-RS implementation like CXF or Jersey. Define an XML schema for
your interface objects, and generate the JAXB-annotated classes from the
schema. Set your controllers to consume and provide JSON.
This won't let you strictly validate a JSON object against the schema, but
it does provide most of the expected semantics of a defined schema driving
the structure of JSON objects.
Interesting. I think I might have been the one who asked.
It seems like there is actually quite a lot of stuff out there in various
languages around this.
Doesn't surprise me given the notion that JSON is often considered a
better choice than XML, and yet there are whole industries out there still
embracing XML schemas.
Dan
-----Original Message-----
*Sent:* Tuesday, November 12, 2013 9:23 AM
*Subject:* [seajug] JSON Schema
Someone asked me at the meeting if there was such a thing as a JSON Schema
- turns out there is (at least something early).
http://json-schema.org/
https://github.com/FasterXML/jackson-module-jsonSchema
Haven't looked into it to see how robust, etc. But, it exists. ;)
Cheers,
-Will
--
"And the users exclaimed with a laugh and a taunt: It's just what we
asked for but not what we want." -- Unknown