OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev]

Two other disruptors for SGML/XML:

1. Offshoring and outsourcing.

SGML was really all about getting smarter, higher quality, data enhancement, automation. Offshoring and outsourcing have all about cheapness. Who needs a big brain if you have 1000 fingers?

2. Agility. 

The classic analysis processes that people have for markup languages only fits the waterfall world: your committee designs the schema, it is done in a stage before or separate to implementing software, probably a separate team, no sense of YAGNI or MVP, any feedback is a long loop or not possible, there is no minor versioning built into XML namespaces to allow identification of schema versions without breaking. 

The more that people need agility, the less that the monolithic standard schema independent of tools or COTS libraries fit in. 


On 24 Mar 2017 09:32, "Peter Flynn" <peter@silmaril.ie> wrote:
On 03/23/2017 02:34 PM, Steve Newcomb wrote:
> On 03/22/2017 07:54 PM, Peter Flynn wrote:
>> Given that hardly any automotive documentation is in XML (or even SGML)
>> any more ("too hard"), it's probably moot for this group, unless we want
>> to start a user-supported tractor-documentation project:-
> I would argue, smilingly, that Peter's "too hard" observation is
> on-topic.

This has happened in another well-known field too: LaTeX (see

Like LaTeX, XML is not "difficult", it's just "different", both from
wordprocessors and from conventional programming languages.

Writers wouldn't like it because of the many reasons I have gone into
before; programmers hate it because it's not _per se_ a programming

> If the XML community doesn't choose to respond to change, or even
> acknowledge it, it is moribund.  Adapt or die.

It will eventually be superseded by something else. In the meantime it
is receding into the wainscoting as it should: invisible to anyone
except ourselves, but sitting there doing its job.

> P.S.: SGML was "too hard", too.  The transformation into XML involved
> shedding features that, in retrospect, were solutions to problems that
> had once been considered compelling.

Unfortunately, once editors had been written to enable one-click (well,
maybe two-click) markup insertion and other markup manipulation, the job
was considered done. There is ample scope for editors which do a better
job for actually authoring in XML, especially for non-XML-expert
authors, but publishers are largely uninterested in this route, having
been bitten too many times in the past.



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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS