Re: [xml-dev] What is XML's sweet spot?

["Simon St.Laurent" <simonstl@simonstl.com>]

All of that is true, though to be honest I'm finding HTML handling more 
and more of the use cases in 1-3.  I find data-* attributes a sadly 
decayed remnant of architectural forms, but they seem capable of 
handling the load.

XML remains awesome, though, for documents with a dose of DIY. Sometimes 
that's just access to the content as text and tags, but it can be a lot 
more.  When you know there will be a transformation step later - and 
especially when you have control of that transformation - you're free to 
apply markup in ways that fit the document and even your current needs.  
(You can, of course, use data-* attributes if you want to live in HTML 
or prefer verbosity.)

I'm currently retrofitting a lot of content I wrote in HTML with a book 
format in mind, figuring out how best to represent it both for a linear 
path through the content and for more random access. Having the freedom 
to modify structures over time and the tooling to automate many of those 
modifications is both more powerful and more fun than the usual model of 
cooking up all the structures beforehand.  I may (or may not) include 
XLink in the mix at some point soon.

If your XML spends its entire life locked in a prison of pre-determined 
structures, you're missing out on what it can really do.

Thanks,
Simon St.Laurent


On 2/18/2016 7:17 AM, Costello, Roger L. wrote:
> Hi Folks,
>
> The recent discussion titled "Protocol Buffers - Why not use XML" was very interesting. Of particular interest to me was the discussion's sub-theme:
>
> 	What is XML's sweet spot?
>
> Here are excerpts from some of the responses:
>
> Liam Quin, the XML Activity Lead for the W3C wrote [1]:
>
> 	[XML's] sweet spot was and remains encoding, archiving,
> 	interchange & processing of complex documents
>
> 	the Enterprise XML people (Web Services) and the "XML is
> 	to replace HTML" people managed to scare away a lot of
> 	potential XML users
>
> Arjun Ray wrote [2]:
>
> 	the authors [of a paper criticizing XML] do go wrong in
> 	characterizing XML as a "mechanism for serializing structured
> 	data", which is precisely where all the bad karma originates.
>
> 	if the question is "a flexible, efficient, automated mechanism for
> 	serializing structured data", then just about all of the time XML is
> 	_not_ the answer.
>
> 	But how about marking up documents - where free flowing text and
> 	annotations are the rule [XML is well-suited to handle this]
>
> So what does all that mean? Here's what I think Liam and Arjun are saying:
>
> 1. Use XML when you have complex documents, such as the kind of semi-structured documents that Word creates. So an XML encoding of a Word document is a good use of XML.
>
> 2. Use XML when you have free-flowing text and you want to periodically insert markup on certain portions (e.g., put a <name>...</name> tag around each name in a body of text). In XML terminology, these are "mixed content" documents.
>
> 3. XML is well-suited to data that needs to be archived and used 5, 10, 50 years from now.
>
> 4. XML is not well-suited as a data exchange format for web services. There are better formats for this, such as JSON, Protobufs, AVRO, Thrift.
>
> 5. XML + XSLT is not a good substitute for HTML.
>
> That's how I interpret their comments. Is that how you interpret their comments? Do you agree with them?
>
> /Roger
>
> [1] http://lists.xml.org/archives/xml-dev/201602/msg00005.html
>
> [2] http://lists.xml.org/archives/xml-dev/201602/msg00011.html
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php