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

["Simon St.Laurent" <simonstl@simonstl.com>]

On 4/28/13 1:48 PM, David Lee wrote:
>> So you're willing to build transformations to get senders' data
>> into your systems.
>
> Done, piece of cake

They send you anything, and you take it?  Are you actually processing 
it, doing something more than storing and sharing the data?

>> 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.

Yes, definitely 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.

Audio and video are usually cases where it could be done, but it's hard 
to imagine why.

>> [No need to answer in detail or give away organizational names, or
>> the store...]
>
>>
>> (1) JSON formats are underspecified,
> Yes

It's funny to me that I've heard so little protest on that except from 
XML folks.  I know not everyone loves Crockford's railroad diagrams (at 
<http://json.org>), and they certainly don't spend effort telling what a 
number is.  (Though ECMA-262 might be what's supposed to tell you.)

YAML, intriguingly, explicitly follows JSON's lead on this:

<http://www.yaml.org/spec/1.2/spec.html>

(And YAML's roots are in XML via SML.)

>> (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 more

I'm pretty sure I can kill most other programming languages by sending 
them integers that are completely ordinary in Erlang.

I don't think there's a reason you couldn't demand ISO 8601 dates in 
JSON, except that I'm not sure there's a less liked date format out there.

>> (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

So how do you sort these things out?  Do you talk with the people 
getting your data?  Do you bounce things off their systems to try to 
figure out what happens?

> 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.

All of this brings me back to the opening of this thread, which I don't 
think you disagree with:

XML's greatest cultural advantage over JSON...

is that it includes a much richer and more nuanced understanding of
transformations.

Thanks,
-- 
Simon St.Laurent
http://simonstl.com/