std.xml2 (collecting features)

[Marco Leise via Digitalmars-d]

Am Sat, 09 May 2015 10:28:52 +0000
schrieb "Joakim" <dlang at joakim.fea.st>:

> On Monday, 4 May 2015 at 18:50:43 UTC, Marco Leise wrote:
>
> > You two are terrible at motivating people. "Better D doesn't
> > support it well" and "JSON is superior through-and-through" is
> > overly dismissive.
> > …
> 
> You seem to have missed the point of my post, which was to 
> discourage him from working on an XML module for phobos.  As for 
> "motivating" him, I suggested better alternatives.  And I never 
> said JSON was great, but it's certainly _much_ more readable than 
> XML, which is one of the basic goals of a text format.

Well, I was mostly answering to w0rp here. JSON is both
readable and easy to parse, no question.
 
> > Remember that while JSON is simpler, XML is not just a
> > structured container for bool, Number and String data. It
> > comes with many official side kicks covering a broad range of
> > use cases:
> >
> > XPath:
> >  …
> >
> > XSL and XSLT
> >  …
> >
> > XSL-FO (XSL formatting objects):
> >  …
> >
> > XML Schema Definition (XSD):
> >  …
> 
> These are all incredibly dumb ideas.  I don't deny that many 
> people may use these things, but then people use hammers for all 
> kinds of things they shouldn't use them for too. :)

:) One can't really answer this one. But with many hundreds of
published data exchange formats built on XML, it can't have been
too shabby all along.
And sometimes small things matter, like being able to add comments
along with the "payload". JSON doesn't have that.
Or knowing that both sender and receiver will validate the XML the
same way through XSD. So if it doesn't blow up on your end, it will
pass validation on the other end, too.


Am Sat, 09 May 2015 13:04:57 +0000
schrieb "Craig Dillabaugh" <craig.dillabaugh at gmail.com>:

> I have to agree with Joakim on this.  Having spent much of this 
> past
> week trying to get XML generated by gSOAP (project has some legacy
> code) to work with JAXB (Java) has reinforced my dislike for XML.
> 
> I've used things like XPath and XLST in the past, so I can 
> appreciate
> their power, but think the 'jobs' they perform would be better 
> supported
> elsewhere (ie. language specific XML frameworks).
> 
> In trying to pass data between applications I just want a simple 
> way
> of packaging up the data and ideally making 
> serialization/deserialization
> easy for me.  At some point the programmer working on these needs
> to understand and validate the data anyway.  Sure you can use 
> DTD/XML Schema to
> handle the validation part, but it is just easier to deal with 
> that
> within you own code - without having to learn a 'whole new 
> language', that
> is likely harder to grok than the tools you would have at your 
> disposal
> in your language of choice.

You see, the thing is that XSD is _not_ a whole new language,
it is written in XML as well, probably specifically to make it
so. Try to switch the perspective: With XSD (if it is
sufficient for your validation needs) _one_ person needs to
learn and write it and other programmers (inside or outside
the company) just use the XML library of choice to handle
validation via that schema. Once the schema is loaded it is
usually no more than doc.validate();
(There is also good GUI tools to assist in writing XSD.)
What you propose on the other hand is that everyone involved
in the data exchange writes their own validation code in their
language of choice, with either no access to existing sources
or functionality that doesn't translate to their language!
 
-- 
Marco