Re: [OT] Re: Lessons learned from the XML experiment

On Fri, Nov 15, 2013 at 3:39 PM, Uche Ogbuji <uche@ogbuji.net> wrote:
> On Fri, Nov 15, 2013 at 8:34 AM, David Sheets <kosmo.zb@gmail.com> wrote:
>>
>> On Fri, Nov 15, 2013 at 3:20 PM, Uche Ogbuji <uche@ogbuji.net> wrote:
>> > On Fri, Nov 15, 2013 at 8:02 AM, David Sheets <kosmo.zb@gmail.com>
>> > wrote:
>> >> On Fri, Nov 15, 2013 at 2:59 PM, Uche Ogbuji <uche@ogbuji.net>
>> I need to transmit a binary blob. Should I use null-terminated strings?
>
>
> So why are you using XML again?

This is a general question: are null-terminated strings the right
representation for transmitting binary blobs?

Why not?

If I decided to use null-terminated strings to transmit a binary blob,
would it be a "C WTF"?

>> >> Could you please explain how this is a problem with overly strict data
>> >> typing being more important than interpreting text in XML? I don't
>> >> understand.
>> >
>> >
>> > http://adtmag.com/articles/2002/12/01/xml-class-warfare.aspx
>> >
>> >
>> > http://adtmag.com/articles/2003/01/31/the-worry-about-program-wizards.aspx
>> >
>> > And overall, since I'm wearying of this week's revival of perma-threads
>> > from
>> > 2000-2003, I'll finish with my own version of serenity, which is the
>> > opposite of Timothy Cook's
>> >
>> > http://adtmag.com/articles/2002/09/30/serenity-through-markup.aspx
>>
>> I read these articles and they don't seem to address why overly strict
>> data typing is the cause of this particular problem.
>>
>> Is it because the recipient is ignoring the data type of "string" and
>> instead deciding to treat certain strings as special values?
>
>
> I believe I made the connection in the above, re-quoted below:

Sorry, I'm still not understanding how this description involving a
stack of questionable technologies relates to the problem of typed XML
transmission vs text XML transmission.

Does XSD have a type for "string or null" that uses the string "null"
to represent the null value?

>> I'm not sure what you mean by "a problem with XML." The problem is
>> manifold,
>> and starts with the XSD data typing system and the way the PSVI
>> subordinates
>> data typing to the original text. It compounds as SOAP/WSDL builds on top
>> of
>> PSVI to wire in assumptions of text interpretations in code. The true
>> fault
>> is with the developer who coded the tool with a careless fencepost that
>> actually circumvented the datatyping system altogether, but that's the
>> entire point of this "Lessons learned" thread: when you make things so
>> complex that few developers can understand and get them right (and I do
>> mean
>> few; I have experience to back that up) then you can hardly always look to
>> shift blame on the developer when they get it wrong.

Oh, I see. The developer circumvented the type system because it was
too complex? And then the developer wrote software with a type error?
And so the developer's tools were at fault? Is that what you're
saying?