Re: [xml-dev] Transformational reciprocity (was [xml-dev] XML'sgreatest

[David Lee <dlee@calldei.com>]

>> 
> 
> So you're willing to build transformations to get senders' data into your systems.
Done, piece of cake
> 
> Just one time per conversation, or regularly, or am I misreading that and you're really only willing to let them send you data in your own specified format?

For JSON it's 
Generalized.  any JSON document transformed into XML losslessly and reversibly with no specaIal custom sauce.   The customer can get the JSON back without knowing it was transformed under the hood.   There a few tricks to handle particularities of JSON member Names and text chars not valid in XML 1.1  but in general the process is not difficult.
There are many examples of this publicly available, some better then others but the problem is tractable.   

For other formats it may be one off.  But for the most part getting any data format INTO XML is usually not difficult.  But sometimes it's not cleanest thing if data models are too different.
To date however I have found no other format then XML that can handle the the widest variety of models reasonably well.   There are better formats for some models of course ... So if your goal is to find the best representation for a single model and you don't care if its ONLY good for that then usually another model is better suited. ...   Providing you are willing to design it and write the infrastructure to use it.   A good example is video.  Not a great fit for XML even for EXI ... 
But it could be done.



> 
> [No need to answer in detail or give away organizational names, or the store...]

> 
> (1) JSON formats are underspecified,
Yes
> (2) JSON formats aren't a natural conversion from your usual internal formats,
JSON has too few and too limited data types to represent "reasonable" data.
( where "reasonable" is subjective of course.  If you have JavaScript data model JSON fits well)
This is not XML specific.  Dates and 64 bit integers are examples.  There are many mo


> (3) The receiving side isn't responsive to queries, or
> (4) You don't feel you should have to transform your outgoing data?
Neither.   Transforming data is what I do.
The problem is if the data has no representation AT ALL in the target format.
Then everyone gets mad 

This is in general true if ALL data transformations. But. IMHO particularly annoying in JSON which bills itself as being precisely for this use ... Due ironically to its greatest benefit.  Simplicity.



> 
> Similarly, do you convert your data to the XML formats the recipients expect?  (I'm guessing that would address 1 and 2 at least partially.)

Certianly.
Well "I" is inaccurate.   The ability to do so exists,  the details vary on the target format specifics.
"I" personally am not usually involved in the specific transformations but rather the tools that enAble them.
That is, of course, one of XML's greatest strength.  The large set of mature tools for transformations.  Which is partly offset by its weakness ... Complexity ... Or rather I suggest ore ieved complexity.  You don't actually HAVE to use more XML features or tools than want
Unless forced to by a 3rd party making use of such features.  It's a balance.


> 
> Thanks,
> -- 
> Simon St.Laurent
> http://simonstl.com/
> 
> _______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>