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
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
>
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
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
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
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
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
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
>
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
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:
>
>
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
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,
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
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
14 matches
Mail list logo
