RE: [xml-dev] XHTML 2 Working Group won't be renewed?

["Len Bullard" <cbullard@hiwaay.net>]

It wasn't generally useful but it was occasionally particularly useful, eg,
setting tree depth.

How many really useful parsers did we end up with anyway?  In the long term
it turned out that the way to control the web was to be a browser
implementer, not a specification or standards writer, which was what was
predicted.  Andreesen wanted to put the operating system in the browser and
others wanted browsers interoperating in operating systems.  Recent
announcements show that everyone has changed sides as soon as it was
tactically convenient. 

So I think the argument over variant syntaxes pales in comparison.  None of
these are real interoperability problems.  It remains the case that if you
want limited data portability (ie, limited features) you use XML, and if you
think that is too restrictive you can implement SGML if you have the chops.
If you don't, you fail.

len

-----Original Message-----
From: C. M. Sperberg-McQueen [mailto:cmsmcq@blackmesatech.com] 
Sent: Thursday, July 09, 2009 5:56 PM
To: Peter Hunsberger
Cc: C. M. Sperberg-McQueen; Jim Tivy; Pete Cordell; XML Developers List
Subject: Re: [xml-dev] XHTML 2 Working Group won't be renewed?


On 9 Jul 2009, at 16:04 , Peter Hunsberger wrote:

> On Thu, Jul 9, 2009 at 4:25 PM, Jim Tivy<jimt@bluestream.com> wrote:
>> Not a good idea for an open interoperatable data format.
>
> If part of the spec is a way to figure out what delimiters are being
> used in any given instance, then I'd argue the exact opposite.  I
> believe this was the case for SGML (anyone?)

The definition of variant syntaxes is indeed allowed
by SGML.  At least one SGML processor supports it in
full generality, or claimed to the last time I looked.
I don't believe I can name a second parser that supports
the feature in all its gory detail.  The definition of
variant syntaxes is hampered by the fact that ISO 8879
gives no particular guidance (that I can find) about
how to ensure that the resulting grammar is unambiguous
or can be parsed with bounded lookahead.

Personally, I think that giving SGML the ability to
define variant syntaxes may well have been necessary to
get ISO 8879 (the SGML spec) finished and generate the
necessary consensus around it; I suspect that some people
were willing to work on it because they expected to use
variant syntaxes a lot, and some people may have decided
not to oppose it because of the variant syntax feature.
But apart from things like the maximum length of names
I don't remember the ability to support variant syntaxes
being really important in SGML practice for most users.
(Software Exoterica's work on the Cinemania project may
be a counter-example, but I'm not sure they used a
variant syntax.)  In practice, faced with the choice of
defining a variant concrete syntax that would make
troff or DCF script (or even DCF GML) a conforming
SGML syntax (and then what -- claiming that troff or
DCF was a conforming SGML processor?), or just switching
to the reference concrete syntax, the marketplace voted
overwhelmingly with its feet and adopted the reference
concrete syntax.

Based on that experience, in this case I think Jim Tivy
is right:  variant concrete syntaxes are usually more
trouble than they are worth.  They impose a cost on all
implementors (and all users) of the language, and provide
benefit either to a very small number of users or to none.

YMMV, of course.

Michael Sperberg-McQueen


-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************





_______________________________________________________________________

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