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 5:32 PM, Michael Kay <mike@saxonica.com> wrote:
>>
>> Further, you made the claim that "XML is not designed for nodes". If
>> you are unwilling to defend this claim, it, too, must be rejected.
>>
>
> No, let's be quite clear. You, David, made the claim that XML is designed for nodes, and Uche rejected that claim. The onus is on you to prove your claim, not the other way around.

Actually, I made this claim in response to his that XML was at fault.
I am only really interested in what evidence he has to support that
claim. I am happy to be shown that "XML is not designed for nodes" or
indeed that "Nothing can be said as to whether XML was or was not
designed for nodes". In fact, it appears (from below) that this latter
statement is the truth as the original specification primarily
concerned the XML serialization rather than any data model.

When a participant in a debate makes a definitive assertion like
"Absolutely not", I expect some sort of justification for this
assertion. To not justify such a rejection is rude and pointless.

> I don't know exactly what "designed for nodes" means, but it suggests to me an idea that the designers of XML had tree-based data models firmly in mind as an influencing factor during the design process.
>
> It's always difficult to discover what designers were thinking when they produced a specification, but with XML it's easier than usual because
>
> (a) the specification contains a list of design goals, (section 1.1) and
>
> (b) one of the authors of the specification, Tim Bray, produced an annotated edition here:
>
> http://www.xml.com/axml/testaxml.htm
>
> Now, in the list of goals, the closest we come to any mention of a data model is the goal "It shall be easy to write programs which process XML documents"; but Tim Bray's gloss on this statement makes it clear they were thinking that it should be easy to write an XML parser. So there is absolutely nothing in the spec about the ease of writing XML-consuming applications. Which is a rather remarkable omission, and puts XML in very stark contrast to JSON.
>
> Similarly, in the annotated specification, mentions of trees, nodes, and data models are conspicuous by their absence.

The grammar contains nested, delimited spans. The specification
primarily concerns serialization. Developers wishing to model data in
XML will be using the XML grammar which contains nested, delimited
spans.

The specification was wise not to specify any particular internal
representation as structures that are not trees are equally
appropriate. For instance, event streams are quite common.

All of this is neither here nor there, however, as we have come no
closer to actually understanding how XML is actually at fault for this
SOAP debacle.

> Now I think we can confidently say that the designers of XML were well aware of the possibility of modelling a document as a tree of nodes; we must therefore assume that the absence of any mention of such a model is deliberate. Perhaps the designers had a tree model at the back of their minds and felt it could be added later, but that would be speculation; all the evidence is that they consciously decided data models were out of scope. Which in my view is unfortunate, but that's not the point.
>
> We have a tradition on this list of showing each other respect, and I think you fell short of that standard in your response to Uche.

I did not intend to be disrespectful and I am sincerely sorry if I
have behaved poorly. If you'd be so kind as to point out how I have
disrespected Uche, I would be appreciative so I will not make the same
mistake in the future.

I am subscribed to this mailing list to learn about XML and its
related concepts. I am not enthused when I try to learn about these
topics by requesting evidence to support definitive claims and I am
met with flip responses and evasion. I believe that this mailing list
should strive for a high level of discourse that genuinely benefits
participants and observers.

The question stands:

What can we learn about the design of XML from an XML web service
developer's modeling a null value as the string "null"?

Thanks,

David

> Michael Kay
> Saxonica
>