[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: What are the practical, negative consequences ofthinking t

• From: u123724 <u123724@gmail.com>
• To: "Costello, Roger L." <costello@mitre.org>
• Date: Thu, 16 Feb 2017 15:22:07 +0100

I think what Simon meant is that XML originally is (or should be seen)
primarily as a text format, and that its constructs such as entity
references, regular content models, processing instructions,
attributes, etc. make  sense for this use case first and foremost. On
the other hand, when you merely want to represent a component data
model (where serialization order of dissimilar items relative to each
other tends not to matter) none of XML's features help that much, even
though XML can be used to represent component models obviously, and
frequently is.

For the latter, data-oriented use case, XML is sometimes accused to
become verbose/redundant, eg. by needing explicit end-element tags
when nesting order could be more succinctly represented in eg. JSON.
Also, XML and markup in general involves a schema design (a deliberate
design decision wrt. how the external form of your data is
represented, due to markup not being about typical co-inductive data
structures such as arrays/maps/lists) when going from most
program-internal/in-memory representation to markup, whereas eg. JSON
has a canonical representation for in-memory representations (as long
as these don't involve shared subcomponents/subexpresssions). Whether
you consider that an "impedance mismatch", or whether you consider
that desirable depends on your application; for example, back in the
in SOAP/WS* days, for many it was considered desirable to have a
schema-first design, and not tie the external representation of your
data/your protocol to your choice of programming language.

From a practical PoV, in a context where you already make use of XML
for text authoring, you'll be using XML for data-oriented use cases as
well to have a uniform data representation format and for being able
to use the same tools for manipulation/extraction. On the other hand,
when you don't do text, I think its fair to say that other
representations such as CSV, JSON, S-exprs, Turtle, or some of the
newer compact binary formats, can be a better choice.

However, even non-text use cases can benefit from XML's availability
of mature/robust/rich tooling and staffing (in Java and other
enterpricy environments at least), and I think for typed
serializations JSON/JSON-Schema is no match to XML/XSD in terms of
usage and functionality.

(Thanks Roger for pointing out to me that I didn't sent to the list)

On Thu, Feb 16, 2017 at 1:00 PM, Costello, Roger L. <costello@mitre.org> wrote:
> Simon St. Laurent wrote:
>
>
>
> Ø  I think that none of the data-centric cases
>
> Ø  where this conversation tends to take place
>
> Ø  are even appropriate use cases for XML at
>
> Ø  this point.
>
>
>
> That is a fascinating statement Simon!
>
>
>
> Would you elaborate please? I’d like to understand more fully what you mean.
>
>
>
> Isn’t XML necessarily about data, i.e., data-focused, data-centric?
>
>
>
> What are the appropriate use cases for XML at this point in history?
>
>
>
> /Roger

• References:
  • What are the practical, negative consequences of thinking thatattributes are metadata?
    • From: "Costello, Roger L." <costello@mitre.org>
  • Re: What are the practical, negative consequences ofthinking that attributes are metadata?
    • From: Mukul Gandhi <gandhi.mukul@gmail.com>
  • Re: What are the practical, negative consequences ofthinking that attributes are metadata?
    • From: "Simon St.Laurent" <simonstl@simonstl.com>
  • RE: What are the practical, negative consequences ofthinking that attributes are metadata?
    • From: "Costello, Roger L." <costello@mitre.org>