[XML-DEV Mailing List Archive Home]
[By Thread]
[By Date]
[Recent Entries]
[Reply To This Message]
Re: Another way to present XML data
- From: yamahito <yamahito@gmail.com>
- To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
- Date: Thu, 14 Sep 2017 07:52:52 +0000
> It's true that JSON is more human readable than XML for tree-structured data.
With respect, that is an opinion presented as a fact without any evidence: you have every right to feel that way, but no right to expect everyone to agree with you.
XML is, for me, primarily a markup language, as its name suggests. As Michael says, mixed content is not an edge case.
> Not recognizing that will just help JSON getting more users.
If JSON is the right tool for the job, as it often is, it's great that people use it. I support them in doing so (literally, on my current contract). I would argue that brevity and human readability (however that is measured) are poor selection criteria in most cases.
I find it incomprehensible that there seems to be this attitude that we must regard JSON and XML as rivals: choose the best tool for the job, especially since those parts of the XML tool chain which JSON lacks now do such a good job of supporting it (e.g XSLT as a transformation language).
Tom
> As David alludes, this shows the lie of JSON being more human readable (at least as a general rule).
It's true that JSON is more human readable than XML for tree-structured data. Not recognizing that will just help JSON getting more users.
I think the true strength of XML lies in its DOM. My goal was to prove that it's possible to serialize XML DOM documents differently, in a way that is as readable as JSON. I think I've succeeded to prove the point. My SML format is strictly equivalent to standard XML. Files can be converted between the two formats reversibly. And for pure tree-structured data, it's arguably even simpler to read than JSON, as it uses even fewer punctuation characters. For mixed data, I've failed. Not in the sense that it's not equivalent to standard XML. It is. But in the sense that it's not simpler. It's more complex actually. (But still shorter though.)
So if you work with mixed data, like in XHTML data, then of course keep using standard XML. And if you work with XML-based languages or trees of data, with no mixed data in them, then I think most people find it much easier to convert files to my SML format to review or edit them.
Objet: Re: Another way to present XML data
> p {u underlined ;i italic}
As David alludes, this shows the lie of JSON being more human readable (at least as a general rule).
> Sebastian was shocked that I would expect different results to be passed into the application depending on whether a DTD/Schema as used or not
This surprises me: surely the ability to redefine entity expansion alone sets a precedent for DTD dependency?
> It would, of course, be much better if we fixed the problem and went back to the rule that space in Mixed Content is significant, and all else is insignificant, when it is possible to identify the context as Mixed Content.
Of course, part of the problem is that it ISN'T always possible to identify content as mixed content reliably without more information.
On Wed, 13 Sep 2017 at 16:52 John P. McCaskey < mailbox@j...> wrote:
On 9/13/2017 11:42 AM, Peter Flynn
wrote:
On 13
September 2017 11:32:10 yamahito <yamahito@gmail.com>
wrote:
>
The case I often find processors screwing up is:
>
> <p><u>underlined</u>
<i>italic</i></p>
>
> Note the significant whitespace between the <u/>
and <i/>
This case is extremely common, and once of the places we
messed up.
I argued long with
Sebastian
over it: he maintained that because the application must
[apparently
"must"; I never understood why] always receive the same
information from
the parser -- regardless of whether the parser has used a
DTD/Schema or not
-- the rule of removing white-space-only nodes had to be
honoured in all
cases.
I respectfully
disagreed,
holding that iff the DTD (in the case we were discussing) made
it clear
that the context was Mixed Content, then white-space-only
nodes were
*significant* and *must* be passed intact to the application
(ie neither
normalized nor annulled).
Sebastian was
shocked that I
would expect different results to be passed into the
application depending
on whether a DTD/Schema as used or not; I attempted to
persuade him that a
FIXED attribute or a REQUIRED attribute with a default value
would be a
case in point, but we never resolved the matter
satisfactorily.
It's easily fixed in
the
classes of text document with which I usually deal, at the
cost of a few
cycles: in every XSLT template which matches an element type
in Mixed
Content, make the first action a call to a named template
which checks if
the immediately-preceding node is an element node of a type
which would
normally be spaced in the class of text documents you handle;
if so, add a
space token to the result tree.
This needs more
refinement if,
for example, you deal with TEI documents containing
character-level element
markup *within* words (eg lingustic or editorial markup) where
adding space
would be an error. But in the conventional run of textual
material (eg
XHTML, DocBook, JATS...) I have found this rarely causes a
problem.
It would, of course,
be much
better if we fixed the problem and went back to the rule that
space in
Mixed Content is significant, and all else is insignificant,
when it is
possible to identify the context as Mixed Content. But that
would cause too
much pain at this stage; it's hard enough as it is to persuade
text owners
to consider XML as things currently stand -- to change punts
in mid-stream
would not help.
///Peter
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
RSS 2.0 |
|
Atom 0.3 |
|
|
Stylus Studio has published XML-DEV in RSS and ATOM formats,
enabling users to easily subcribe to the list from their preferred news reader application.
|
Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website.
they were not included by the author in the initial post. To view the content without the Sponsor Links please
click here.
|
|