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] A question of necessity

On Thu, 2016-04-28 at 10:14 +0100, sean.mcgrath@propylon.com
> I well remember being shocked at how powerful Synex Viewport - laterĀ 
> known as Softquad Panorama - was, as a hypermedia browsing tool. It
> is a terrible pity that this product disappeared IMO.

Well, I agree. The people buying it didn't understand what it was, I
think (I had already been laid off at the time, though, so I'm not

> Figuring out enough about HyTime AFs to get it set up on my SGML
> corpora wasn't trivial but once it was set up, it worked brilliantly 

It's unfortunate that the XLink working group was a political
battleground. Architectural forms - regardless of syntax - provided a
way to identify links in an existing vocabulary.

The biggest ways XML on the Web failed, from my perspective, were
(1) the lack of an acceptable data binding story (JSON has stepped in
there, thankfully);
(2) the inability of search engines to produce meaningful result
snippets without having to run XSLT, which considerably adds to the
runtime cost of making an index.
(3) the need to hard-wire specific element and attribute names to
specific behaviour, such as xml:id, xml:base, xl:link, making XML
intrude into the user's vocabulary in the body of the document -- if
you have to transform your XML, you might as well make HTML.
(4) the lack of xml:style and xml:script (once we've gone down the
route of hard-wired elements) -- see (2). These days html:style and
html:script can be used, but then you get into...
(5) the inability to define aggregate namespaces or to bind namespaces
to prefixes within XPath means these mixed vocabularies are too hard
for people to process, in practice, with our own tools.
(6) the lack of implicit dispatch in the DOM (a basic tenet of object-
oriented design) made programming with XML in DOM-based systems maybe
ten to a hundred times harder and more error-prone than it could have
been. I've indeed heard of people getting a 10 or even 100-fold
reduction in code size by switching to XQuery.

I've heard it said that scientific advances come only when people who
championed the orthdox view die off. (if John Cowan or Kate Hamilton is
reading this they can identify the source for sure!).

I gave a paper at an XML conference once saying we should have a single
standard way to represent relationships between resources, such as
documents and styles and scripts and DTDs and schemas. Suggesting RDF
turned out not to have been wise, though.

Architectural forms were messy in syntax. At one point when we were
making XML I tried to push for a single standard "xml" element with
"head" and "body" children, so that we would control what went into the
"head" but not the body. There was strong pushback, people saying we
should not reserve any names -- but then we ended up reserving all
names starting with xml, and plenty more besides (the restriction on
xml* has since been dropped in an erratum, which is appropriate since
we never said what "reserved" meant, and it's far from obvious, as
shown by different behaviour across implementations). In a world where
we had an xml/head we'd have had space for an XML instance-based syntax
for architectural forms. -- and an insentive for an instance-based
replacement for DOCTYPE. On the other hand XHTML might never have
happend - maybe that would have been better, though.

What might have been and what has been.
Point to one end, which is always present.

Liam R. E. Quin <liam@w3.org>
The World Wide Web Consortium (W3C)

[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