Re: [xml-dev] [OT] Re: [xml-dev] Lessons learned from the XML experiment

[David Sheets <kosmo.zb@gmail.com>]

On Fri, Nov 15, 2013 at 3:57 PM, Uche Ogbuji <uche@ogbuji.net> wrote:
> On Fri, Nov 15, 2013 at 8:46 AM, David Sheets <kosmo.zb@gmail.com> wrote:
>>
>> 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?
>
>
> Your question nails it in an unintended way. I was clearly talking about
> text. You are talking about null-terminated strings and BLOBs. There is a
> very big and important difference.

I'm talking about type errors of which both this SOAP example and my
example are instances.

> And no, I do not believe that text technologies are right for transmitting
> either null-terminated strings or BLOBs. Why not? Because they're not
> designed for it. You can start learning how so by trying to put a
> null-terminated string into XML.

Perhaps using text to transmit the concept of "null" is also ill-advised...

>>
>> If I decided to use null-terminated strings to transmit a binary blob,
>> would it be a "C WTF"?
>
>
> Of course not, because C is designed for that.

And XML is designed for nodes. The data model designer did not use a
<null> element or take the absence of an element to be a null value,
instead they chose to overload the meaning of a piece of plain text.

>>
>> >> >> 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?
>
>
> From the "null terminated strings" bit and this one, I can tell your
> viewpoint on this is very programmer-literal, and so we're on very different
> worlds in taking lessons from that situation.

I think programmers should design data formats for programs to read
and write, yes. I'm not sure what else you feel you can glean of my
viewpoint. What else do you think I think?

> So the answer is no that's
> not what I'm saying, but Ive already said what I'm saying.

Sorry, I'm still not understanding. You appear to be saying that this
SOAP difficulty is a classic "XML WTF" that is attributable to being
too concerned with typing at the expense of text. Could you perhaps
lay out a series of inferences that lead you to this conclusion?

I'm having a hard time following your train of thought.

Thanks,

David Sheets

> --
> Uche Ogbuji                                       http://uche.ogbuji.net
> Founding Partner, Zepheira                  http://zepheira.com
> Author, Ndewo, Colorado                     http://uche.ogbuji.net/ndewo/
> Founding editor, Kin Poetry Journal      http://wearekin.org
> Editor & Contributor, TNB
> http://www.thenervousbreakdown.com/author/uogbuji/
> http://copia.ogbuji.net    http://www.linkedin.com/in/ucheogbuji
> http://twitter.com/uogbuji