Re: [racket-users] Real-world examples of XML usage?

[Neil Van Dyke]

If you're doing JSON that's not totally ephemeral (not like sending a 
few keystrokes for a live search JS widget is [1]), but something more 
like returning information from a database, you could do JSON yet get a 
little closer to some of the benefit of XML (like "what the heck is this 
data that we found in a file, or as an attachment in our database") by 
including a little metadata in the top level of the JSON.


Doing this metadata might also comfort engineers who care deeply about 
systems, [2] and who are always reasoning about uncertainties like 
possibilities and risks.


Such metadata can include a URL for the schema/documentation of the 
message (which references different spec for the metadata envelope), 
what software produced it, a timestamp, maybe what server produced it, 
maybe a more-specific characterization of the content separate from the 
schema but perhaps not implicit in the content (maybe request REST data, 
or request URL), maybe there's an industry sector standard to reference 
(much like some XML DTDs/schemas), maybe you have a data sensitivity 
model or authorization model that's appropriate for tagging sensitivity 
of messages, etc.


If you're working on a startup and moving fast, and there's no standards 
yet, and you don't want to figure out metadata right now, you might just 
decide to use a `write-foo-json-message` procedure everywhere, which 
only leaves a placeholder for metadata in the JSON structure.  When you 
later can figure out metadata, that Racket procedure can get some new 
required keyword arguments for necessary info (giving you compiler 
errors until you visit each call site), though you'll still have to 
search through the JS code, to see where you should be using the 
metadata (but at least the more fragile JS code will keep working, 
because you had the placeholder in the JSON there from the start).


[1] That might be a bad example of ephemeral today, with some of the 
dotcom snoopers capturing and analyzing even fine-grained mouse move 
events. :)


[2] I care, without being married to anything, but it's unsettling how 
interesting mundanity of XML and JSON details can be, for a moment. :)


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[David Storrs]

On Tue, Feb 5, 2019 at 11:18 AM Konrad Hinsen
 wrote:
>
> David Storrs  writes:
>
> > to type things.  In addition, most developers that I've worked /
> > talked with will typically reach for the JSON API before the XML one
> > given the choice.  I think the ground truth suggests that JSON is a
>
> Ah, I see, we are working in very different contexts. In a Web API, I'd
> go for JSON as well. After all, you need little more than a
> serialization format for the input and output parameters of the API functions.
>
> But my main use case is data storage in self-contained files stored in
> databases (including Git repositories), to be read by existing or
> yet-to-be-written software. The data can be quite complex, so any
> machine-readable description of its structures is a plus. XML on its own
> already provides the tag structure, and a schema adds much more
> documentation, still in a standard format.

Ah, I see.  So the answer to "What is a real-world case where it makes
sense to use XML over anything else?" is "When storing data on
disk."[1]  Okay, I can get behind that.  Thanks.


[1] DBs are a special case of 'on disk'.
>
> Konrad.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[Konrad Hinsen]

David Storrs  writes:

> to type things.  In addition, most developers that I've worked /
> talked with will typically reach for the JSON API before the XML one
> given the choice.  I think the ground truth suggests that JSON is a

Ah, I see, we are working in very different contexts. In a Web API, I'd
go for JSON as well. After all, you need little more than a
serialization format for the input and output parameters of the API functions.

But my main use case is data storage in self-contained files stored in
databases (including Git repositories), to be read by existing or
yet-to-be-written software. The data can be quite complex, so any
machine-readable description of its structures is a plus. XML on its own
already provides the tag structure, and a schema adds much more
documentation, still in a standard format.

Konrad.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[David Storrs]

On Tue, Feb 5, 2019 at 2:17 AM Konrad Hinsen  wrote:
>
> David Storrs  writes:
>
>
> > I was specifically thinking of JSON.  It allows for encoding all the
> > essential structure of XML in far fewer characters, meaning there's
> > less data to send over the wire. It's more human-readable. There are
>
> JSON is basically a serialization notation for nested lists and hash
> maps. What it lacks compared to XML is tags and namespaces. You have to
> add a layer of conventions on top of JSON to get some form of data
> identification, and since that layer is not standardized, it's likely to
> get messy once you need to work with data from different sources.
>
> JSON is probably a good choice if all software working with your data is
> under your control. Less so if the client software pool is open-ended or
> if the data may be archived for an indefinite future with different
> software tools.

At the risk of sounding snarky, there are a ton of major services that
provide JSON interfaces to their APIs.  Most provide XML as well, but
people are still going to prefer reading the documentation to poring
over the DTD in order to figure out what's required, optional, and how
to type things.  In addition, most developers that I've worked /
talked with will typically reach for the JSON API before the XML one
given the choice.  I think the ground truth suggests that JSON is a
perfectly fine choice for open-ended services that are being consumed
by software not under your control.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[Konrad Hinsen]

David Storrs  writes:

>> This:
>>
>>https://mosaic-data-model.github.io/
>
> That looks very cool, and like something that I'd like to talk to you
> about professionally.  Would you mind if I contact you off-list?

Not at all!

> Wow.  That's impressive, and seems like something that could have a
> real impact.  Kudos.

We'll see. The whole idea is still very hard to "sell".

>> In both cases, the motivation was to facilitate access to the data for
>> as many software developers as possible. There are good XML support
>> libraries for most programming languages, even Fortran.
>
> True, but most languages also have good JSON tools, YAML tools, etc.

Yes, those are the obvious competitors. But YAML is probably worse than
XML in terms of overengineering (see
e.g. 
https://medium.com/@lefloh/lessons-learned-about-yaml-and-norway-13ba26df680)

> "Overengineered" is a good way to put it -- I think that's what
> bothers me about XML.  I do grant its utility, I'm simply not
> convinced that most of it is necessary for most cases.

Me neither!

> I was specifically thinking of JSON.  It allows for encoding all the
> essential structure of XML in far fewer characters, meaning there's
> less data to send over the wire. It's more human-readable. There are

JSON is basically a serialization notation for nested lists and hash
maps. What it lacks compared to XML is tags and namespaces. You have to
add a layer of conventions on top of JSON to get some form of data
identification, and since that layer is not standardized, it's likely to
get messy once you need to work with data from different sources.

JSON is probably a good choice if all software working with your data is
under your control. Less so if the client software pool is open-ended or
if the data may be archived for an indefinite future with different
software tools.

Konrad.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[Philip McGrath]

On Mon, Feb 4, 2019 at 3:22 PM Neil Van Dyke  wrote:

> BTW, you *could* also do both XML and JSON.  For example: for some Web
> services, coming from a very complicated data model, IIRC, the
> engineering process scenario was something like originally the
> requirement was for XML, and then JSON was added as a requirement, and
> additional services were added at some point, and engineering resources
> were tight.  What I ended up doing, that time, was defining a conceptual
> mapping from a subset of XML to JSON encoding, so that a programmer
> wrote the code to construct the XML message, and got JSON for free.
>

I haven't  really used it, but Greg Hendershott has a package flexpr
 that defines a subset of
jsexpr
s
that can also be converted to x-expressions.

You can see many ways to do something like this, and your implementation
> might involve a DSL (perhaps in terms of the data model also used by
> your documentation, and your DSL can even generate Scribble for the XML
> and JSON interface specs for the documentation, separate from any Racket
> API documentation).
>

For Digital Ricoeur, I have in fact made a DSL to express our
project-specific requirements for XML documents. (We start with an external
XML standard, but we use only a minimal subset of the standard and add
additional requirements very specific to our project—e.g. there must be an
author with an xml:id attribute of "ricoeur".) The DSL generates Scribble
documentation and also defines our internal representation of the
documents, including conversion from x-expressions. We've been very happy
with this approach, and using a DSL has given us concrete benefits over
what we were doing before (even in Racket). If anyone is interested, I
discussed how we incrementally moved toward a DSL in my RacketCon talk
 (more specifically this part
), and both the generated documentation

and some details about the DSL implementation

are online.

On Mon, Feb 4, 2019 at 1:34 PM David Storrs  wrote:

> as Neil pointed out, a good
> candidate would be medical data that needs to be readable 100 years
> from now.  My question, however, was about how often those cases
> actually come up in practice


Our main reason for using XML is external standards, but we have found a
benefit along these lines for incremental refinement. The standard we are
are working against is enormous, and, as I said, we use a subset that we
try to keep as small as possible while meeting our immediate needs. That
means we end up iterating our project-specific requirements fairly rapidly,
sometimes in intentionally backwards-incompatible ways. Having a layered
approach to validation—broad, stable requirements validated with general
XML tools plus project-specific requirements checked with Racket contracts,
which we change more agilely—has helped as a sanity check and to give us
some level of consistency across iterations.

You could do this with other formats, too, and I think other formats are
often better choices, but XML's story for validation seems more mature and
more widely supported than, say, JSON Schema.

On Sat, Feb 2, 2019 at 11:57 PM David Storrs  wrote:

> The ability
> to type data (e.g. specify that 'age' elements are measured in days,
> or years, or etc) is a good feature, and I'll give XML that one.


This is actually an annoyance of mine about XML. Many schemas indeed do
specify semantic meaning for data in these ways, and W3C XML Schema
Definitions , for example, does try
to address translating types into the application level. In practice,
though, I don't think I've ever been able to take advantage of this: XML
data comes in as strings, and, even if I know (and have validated) that
some string will be an ISO 8601 date, I still have to deal with parsing it
and often discarding whitespace myself. It's the same with JSON when you
get to more complex types, but at least there are a few more atomic types
than just strings.

-Philip

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[Neil Van Dyke]

Jens Axel Søgaard wrote on 2/4/19 3:38 PM:

(define (html-flash-card)
  ; style: "border:1px solid black"
  @div[class: "col-md-6" ]{
    @div[id: "flash-card-content"]{
      @div[id: "flash-card-question-container"]{
@div[id: "flash-card-question"]{
@h2{Flash Card}
@p{The name of the mathematical exponentiation operator?}
          @p{ $$ c = \sqrt{a^2+b^2} $$}}}
@html-answer-box[]}})


This example looks good, and I like the at-reader.  An alternative, for 
people who love parentheses, and want some to optimize a little more for 
static parts at compile time, here's an approximate (untested) way using 
`html-template`:


(define (example-html-flash-card-1)
  (html-template
    (div (@ (class "col-md-6"))
 (div (@ (id "flash-card-content"))
  (div (@ (id "flash-card-question-container"))
   (div (@ (id "flash-card-question"))
    (h2 "Example Flash Card")
    (p "The name of the mathematical exponentiation 
operator?")

    (p (% $$ c = \sqrt{a^2+b^2} $$
  (%write (html-answer-box))

Or, another way to use `html-template` is to define your own 
application-specific syntax forms that expand to it.  So, if you're 
doing flashcards, you might define `flash-card` syntax that you can use 
like:


  (flash-card
   #:title "Example Flash Card"
   (p "The name of the mathematical exponentiation operator?")
   (p (math "c = \sqrt{a^2+b^2}")))

See "https://www.neilvandyke.org/racket/html-template/; for an example 
of what happens at compile time (specifically, syntax transformation 
time).  It uses only Racket port-writing, and can be combined with other 
port-writing procedures -- it uses no special Racket buffer management, 
nor opportunities with any HTTP server/fronting, nor lower-level OS 
facilities


(Sorry the code of `html-template` itself is more scary than it now has 
to be.  I've done some unreleased work atop this package, for an 
unfunded startup, but no more work on this package itself.)


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[Jens Axel Søgaard]

Den søn. 3. feb. 2019 kl. 05.57 skrev David Storrs :

> There was a discussion in another thread lately about various ways of
> representing XML.  It got me thinking, and I wanted to ask about
> people's practical experience.
>
> What projects have y'all done where XML was the best choice for a
> reason other than "because we needed to interoperate with a service
> that required XML"?
>
> I've never needed to use XML that much -- HTML and CSS for the
> browser, ...


If you count representations of HTML then I am fond of representing HTML as
Racket structures.
Combined with the at-syntax from Scribble one can write code that looks
like:

(define (html-flash-card)
  ; style: "border:1px solid black"
  @div[class: "col-md-6" ]{
@div[id: "flash-card-content"]{
  @div[id: "flash-card-question-container"]{
@div[id: "flash-card-question"]{
  @h2{Flash Card}
  @p{The name of the mathematical exponentiation operator?}
  @p{ $$ c = \sqrt{a^2+b^2} $$}}}
  @html-answer-box[]}})

The example is from

https://github.com/soegaard/urlang/blob/master/urlang-examples/quiz/quiz.rkt

The docs are here:
http://docs.racket-lang.org/html/index.html?q=html

/Jens Axel

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[Neil Van Dyke]

David Storrs wrote on 2/4/19 1:34 PM:

I was specifically thinking of JSON.


Especially if your service interface is always through HTTP/HTTPS, 
there's a good chance that JSON is a great choice for your application.  
(If data will be accessed by someone else directly from files or 
database blobs in this encoding, rather than always coming from the code 
of your server, that might have more of a life-of-its-own quality, and 
maybe XML becomes a little more attractive than it was before.)


When you do a server interface in JSON, you have to do more 
documentation than XML, and be strict about server-side checking:


* If the other side is general solid software engineers / programmers, 
you just need to do good specs, which includes having to be explicit 
about some things that are implied with XML.  With checking as a backup 
to oopses, and to rule out some causes when debugging (preferably at 
least as much as XML would've ruled out).


* If the other side is solid enterprise people who prefer XML, but are 
willing to do JSON, you also need that good documentation.  For good 
engineering, and perhaps to reassure them that this is not substandard.


* If the other side is a brogrammer "smashing some code" by shotgunning 
Red Bull to wash down off-label abuse of other substances, while typing 
syntax flat-out at 200 wpm, they might only skim your docs for a message 
template they can copy, and wing it from there-- so it's a good 
thing that you're validating the heck out their messages at whatever 
syntactic and semantic levels you can. :)  This is one of those times 
that usually-good Internet protocol advice of "...liberal in what you 
accept" is a bad idea (silent HTML "quirks handling", starting in the 
early browsers, was another bad time, in hindsight).


Good news for Racket: For doing processing on JSON, like writing and 
reading and validation and mapping and transformation, Racket DSLs 
and/or list-processing skills might let you do it much better than you 
could, were you armed only with JS.


BTW, you *could* also do both XML and JSON.  For example: for some Web 
services, coming from a very complicated data model, IIRC, the 
engineering process scenario was something like originally the 
requirement was for XML, and then JSON was added as a requirement, and 
additional services were added at some point, and engineering resources 
were tight.  What I ended up doing, that time, was defining a conceptual 
mapping from a subset of XML to JSON encoding, so that a programmer 
wrote the code to construct the XML message, and got JSON for free.  You 
can see many ways to do something like this, and your implementation 
might involve a DSL (perhaps in terms of the data model also used by 
your documentation, and your DSL can even generate Scribble for the XML 
and JSON interface specs for the documentation, separate from any Racket 
API documentation).


BTW, if you end up doing reading of large JSON, and want to stream it 
like SSAX can, rather than slurp it all into memory first, a learning 
exercise a while ago showed it could be done, with a weird but 
potentially useful API.  (I should've emphasized the "learning exercise" 
note that's in the docs, as a liability disclaimer, so just treat this 
as proof-of-concept that you can do JSON processing as streaming, if you 
ever need to.) https://www.neilvandyke.org/racket/json-parsing/


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[David Storrs]

On Sun, Feb 3, 2019 at 7:22 AM Konrad Hinsen
 wrote:
>
> David Storrs  writes:
>
> > What projects have y'all done where XML was the best choice for a
> > reason other than "because we needed to interoperate with a service
> > that required XML"?
>
> This:
>
>https://mosaic-data-model.github.io/

That looks very cool, and like something that I'd like to talk to you
about professionally.  Would you mind if I contact you off-list?

>
> and this:
>
>https://github.com/khinsen/leibniz/

Wow.  That's impressive, and seems like something that could have a
real impact.  Kudos.


> In both cases, the motivation was to facilitate access to the data for
> as many software developers as possible. There are good XML support
> libraries for most programming languages, even Fortran.

True, but most languages also have good JSON tools, YAML tools, etc.


> The other candidates in such circumstances are JSON and YAML, but you
> get a lot more structure for free with XML than with JSON, while
> avoiding the enormous complexity of YAML. I also found some utility in
> schemas and schema-based validation tools, although that universe looks
> heavily overengineered to me. Still, it's work done by others that I
> don't have to repeat myself.

"Overengineered" is a good way to put it -- I think that's what
bothers me about XML.  I do grant its utility, I'm simply not
convinced that most of it is necessary for most cases.

> > On the other hand, XML is extremely heavyweight, thereby slowing
> > parsing and transmission as well as making the data less
> > human-readable.
>
> Compared to what? Special-purpose data format? Design your own language,
> write you own parsers, working at the character level? I don't write
> software in assembly for good reasons, and for the same reasons I want
> higher-level data formats than just character streams.

I was specifically thinking of JSON.  It allows for encoding all the
essential structure of XML in far fewer characters, meaning there's
less data to send over the wire. It's more human-readable. There are
good parsers in all languages, and the output of the parser is a
straightforward datatype. In most cases it parses faster than XML.
(Given parsing libraries in the same language, in most cases,
benchmarks lie, etc.)

XML definitely has useful features that JSON lacks, and I can think of
times when it would make sense -- as Neil pointed out, a good
candidate would be medical data that needs to be readable 100 years
from now.  My question, however, was about how often those cases
actually come up in practice, and what factors different people find
compelling when evaluating XML vs a different interchange / storage
format.

>
> Konrad.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[David Storrs]

On Sun, Feb 3, 2019 at 2:39 AM Neil Van Dyke  wrote:
>
> David Storrs wrote on 2/2/19 11:57 PM:
> > Are there angles here that I haven't encountered or thought about yet?
>
> As a fellow Racketeer with mixed feelings about XML, let me articulate
> for the list an angle you might've already considered...
>
> One reason you might decide to use XML for a system interface (when not
> required to, nor encouraged by it possibly helping sales to some
> customers) is that you want to help the programmers on the other side of
> the interface to be correct, for very selfish reasons.
>
> (We must remind ourselves not to underestimate the capacity for
> incorrectness in software systems development.  We know it's bad, but
> it's worse than that.)
>
> If everyone's messages have to validate to a particular DTD/schema, that
> lets you throw in what's effectively a bunch of checking they can do
> themselves, on their side, gives them blame-pointing error messages, and
> eliminates some of the phases of incorrectness on their end.

This is, I think, saying that XML allows for typed data, as well as
specified structural requirements.  I granted above that types were a
great feature, and I'll definitely concede to structural requirements.

I see your point, although I'm waffling about it.  I think it would be
easier to have, for example, a JSON interface with good error messages
for when messages aren't accepted.  Still, writing the DTD is a
compact way of writing the error messages, much like contracts on a
function.

> When you're considering XML for a particular real-world case, it might
> be helpful to try to think through scenarios of using XML vs. other
> plausible open standards or semi-standards, like Protobuf, or some
> convention over JSON or CSV.  Who all will be on the other end of the
> interface?  How will they implement it?  What's everything that happens
> when the interface spec gets a new version?  How messy is that going to
> be?  How long does this have to keep working (e.g., medical records that
> might need to be interpreted perfectly 100 years and 10 corporate
> acquisitions later)?  Etc.

Very valid points.  Thank you.

>
> BTW, if you do go with XML, you might find RELAX NG Compact syntax to be
> pleasant.

Oh, nice.  I wasn't aware of that, thank you.

Dave

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[Konrad Hinsen]

David Storrs  writes:

> What projects have y'all done where XML was the best choice for a
> reason other than "because we needed to interoperate with a service
> that required XML"?

This:

   https://mosaic-data-model.github.io/

and this:

   https://github.com/khinsen/leibniz/

In both cases, the motivation was to facilitate access to the data for
as many software developers as possible. There are good XML support
libraries for most programming languages, even Fortran.

The other candidates in such circumstances are JSON and YAML, but you
get a lot more structure for free with XML than with JSON, while
avoiding the enormous complexity of YAML. I also found some utility in
schemas and schema-based validation tools, although that universe looks
heavily overengineered to me. Still, it's work done by others that I
don't have to repeat myself.

I think someone suggested s-expressions here. That would be a fine
option, if there were better support for it in non-Lisp languages.

> On the other hand, XML is extremely heavyweight, thereby slowing
> parsing and transmission as well as making the data less
> human-readable.

Compared to what? Special-purpose data format? Design your own language,
write you own parsers, working at the character level? I don't write
software in assembly for good reasons, and for the same reasons I want
higher-level data formats than just character streams.

Konrad.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Real-world examples of XML usage?

[Neil Van Dyke]

David Storrs wrote on 2/2/19 11:57 PM:

Are there angles here that I haven't encountered or thought about yet?


As a fellow Racketeer with mixed feelings about XML, let me articulate 
for the list an angle you might've already considered...


One reason you might decide to use XML for a system interface (when not 
required to, nor encouraged by it possibly helping sales to some 
customers) is that you want to help the programmers on the other side of 
the interface to be correct, for very selfish reasons.


(We must remind ourselves not to underestimate the capacity for 
incorrectness in software systems development.  We know it's bad, but 
it's worse than that.)


If everyone's messages have to validate to a particular DTD/schema, that 
lets you throw in what's effectively a bunch of checking they can do 
themselves, on their side, gives them blame-pointing error messages, and 
eliminates some of the phases of incorrectness on their end.


Incorrectness phases avoided is less work for you (consider if they're 
talking to a service you're selling them, and/or contacting you for 
support when their code is broken, or their floundering becomes an 
enterprise-scale diplomatic problem for you), and less of you waiting on 
them (for, e.g., integration, or a sale),  and presumably makes them 
happier, as well.


There are numerous other ways in software you could accomplish the same 
goals--  *but* XML is a popular open standard, so a lot of mutual 
understanding and agreement is accomplished instantly.


It's possible to not love everything about XML, yet to see that it has 
technical merits, and to see very practical value in a popular open 
standard interface.  The practical value includes that a standard at the 
interface lets you use tools you like more on your side of the 
interface.  This standard gives you the flexibility to innovate with 
Racket+XML, rather than everyone in that sector forced for a decade to 
all use IckyLang 2000 (which, admittedly, has a surprisingly slick 
transparent distributed model, IckySmear).


When you're considering XML for a particular real-world case, it might 
be helpful to try to think through scenarios of using XML vs. other 
plausible open standards or semi-standards, like Protobuf, or some 
convention over JSON or CSV.  Who all will be on the other end of the 
interface?  How will they implement it?  What's everything that happens 
when the interface spec gets a new version?  How messy is that going to 
be?  How long does this have to keep working (e.g., medical records that 
might need to be interpreted perfectly 100 years and 10 corporate 
acquisitions later)?  Etc.


BTW, if you do go with XML, you might find RELAX NG Compact syntax to be 
pleasant.  And/or you could make a schema DSL in Racket that generates 
both various Racket interface code and the XML schemas in standard 
format, and maybe a SQL schema mapping, too (maybe even have your Racket 
DSL also generate some Java code shim for a customer's other system's 
proprietary plugin interface, while you otherwise move the larger system 
to open standard interfaces).


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Real-world examples of XML usage?

[David Storrs]

There was a discussion in another thread lately about various ways of
representing XML.  It got me thinking, and I wanted to ask about
people's practical experience.

What projects have y'all done where XML was the best choice for a
reason other than "because we needed to interoperate with a service
that required XML"?

I've never needed to use XML that much -- HTML and CSS for the
browser, JSON for the wire, SQLite or Postgres for the DB, and (on one
rather memorable occasion) Postscript for the printer.  I'm aware of
the various technologies around XML -- XPATH, XSLT, etc -- but they
haven't featured in any project I've ever needed to do, so I haven't
spent much time on them.  Is that that's something I should find time
for?

I'm aware of two primary features that XML proponents point to for why
XML is worth knowing:  It's self-describing and it's typed.  To me,
the first sounds like a security nightmare of sophistry.  (Real-world
applications are typically going to know the format of the data that
they're consuming, and you certainly do not want to let external data
specify what standards and formats it should be held to.)  The ability
to type data (e.g. specify that 'age' elements are measured in days,
or years, or etc) is a good feature, and I'll give XML that one.

On the other hand, XML is extremely heavyweight, thereby slowing
parsing and transmission as well as making the data less
human-readable.

Are there angles here that I haven't encountered or thought about yet?
 If so, what would you recommend I read up on / look into?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.