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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: is that a fork in the road?

[ Lists Home | Date Index | Thread Index ]
  • To: xml-dev@lists.xml.org
  • Subject: Re: is that a fork in the road?
  • From: Eric van der Vlist <vdv@dyomedea.com>
  • Date: Sat, 06 Jul 2002 22:48:05 +0200
  • References: <5.0.2.1.2.20010302113600.028be010@pop.hesketh.net>
  • User-agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.0.0) Gecko/20020614 Debian/1.0.0-3

Does that ring a bell? It was in March 2001 and I think we are making a 
fair progress toward the fork with this new yet old discussion about 
XQuery and DTS/Schema which can't lead anywhere.

http://lists.xml.org/archives/xml-dev/200103/msg00127.html

Thomas B. Passin is very right IMO suggesting that the border line might 
be simplicity and there are probably two logics and diverging interets 
which are fighting here.

On one side, a bunch of developers and experts who believe that power 
lies in the simplicity of the tools and the concepts and try to "keep it 
simple" and focus on tools which can be developed by individuals while 
on the other side software vendors push for for more complexity which 
they are better prepared to implement in their labs.

I do believe that simple tools are most powerful and I don't feel ready 
to give up the flexibility that the simplicity of technologies such as 
XML 1.0, SAX, XPath 1.0, XSLT 1.0, XSLT Script, Relax NG, RDF (yes, I 
think that even RDF itself is simple), RSS, Schematron, XPipe, Pyxie, 
Regular Fragmentations, XML-RPC, Examplotron, xvif, ... --sorry for the 
cool simple technologies I have not quoted.

I do believe that simple tools are more efficient to solve complex 
problems than complex tools (when you use a complex tool, most of the 
time you just add the complexity of the tool to the complexity of the 
problem) and I think that with W3C XML Schema, XPath 2.0, XSLT 2.0, 
XQuery and others specs that are as bloated and complex the W3C has 
become a danger for XML and is leading it to regression.

Sadly, I think that it's time to fork, time to create a W3R of some 
kind, to see how far we can bring XPath 1.0 and XSLT 1.0 with EXSLT, to 
continue to develop alternative schema languages, in a word, time to 
consolidate the inventive alternative which individuals have started to 
build.

Eric

Simon St.Laurent wrote:
> Wow.  Catching up on a week of XML-Dev is difficult stuff.
> 
> It feels to me like there's a lot percolating in this community right now, 
> and it's not all friendly.
> 
> About a year and a half ago, there was some bloodletting over folks who 
> thought XML 1.0 itself was too complicated, and SML-DEV moved to its own 
> turf.  SML-DEV has produced some good stuff, but had to deal with being 
> called 'splitters' on a regular basis.
> 
> Now we've got a different situation, where 'XML' is growing complex more 
> rapidly than most people speaking here seem to want.  It's not exactly a 
> matter of simplifying, but there are echoes of the previous battle.  This 
> time around, though, it seems like a lot more people are concerned about 
> the complexity issues, perhaps because they've grown by an order of 
> magnitude in the interim.
> 
> I've never been certain that XML-Dev was representative of everyone using 
> XML - I'm quite sure it's not - but it does include a wide variety of 
> developer categories and people who have seen plenty of different projects 
> and kinds of projects succeed and fail.  I've also heard similar complaints 
> echoing through other communities exploring XML, from XHTML folk to random 
> people in bookstores trying to decide if US$50 for a 1200-page book is 
> going to get them all they think they need.
> 
> I don't really know what's going to happen, but I feel like we're at a 
> crossroads, echoing the SML-DEV debate but with very different 
> implications.  I'm hoping that we can all find ways to use 'XML' so that it 
> solves our problems without getting in the way of everyone else's 
> problem-solving, but that doesn't seem to be what's happening right now.
> 
> This chaos is probably good for the health of markup solutions in the long 
> run - these are important issues that come up all the time.  At the same 
> time, I'm worried that users may start looking at XML with a lot more 
> suspicion as the books grow in size, the learning curve climbs higher, and 
> there doesn't seem to be much agreement about what 'XML' should be.  To 
> some extent, the same thing is happening with XSLT.
> 
> Maybe I've just read too much of XML-Dev at one gulp, and I certainly come 
> to this with my own strong set of opinions, but it feels like something 
> different is afoot.  Not necessarily the inevitable march of complex 
> solutions to solve complex problems, either.
> 
> 
> Simon St.Laurent - Associate Editor, O'Reilly and Associates
> XML Elements of Style / XML: A Primer, 2nd Ed.
> XHTML: Migrating Toward XML
> http://www.simonstl.com - XML essays and books
> 
> 
> ------------------------------------------------------------------
> The xml-dev list is sponsored by XML.org, an initiative of OASIS
> <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: xml-dev-request@lists.xml.org
> 
> 



-- 
See you in San Diego.
                                http://conferences.oreillynet.com/os2002/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------





 

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

Copyright 2001 XML.org. This site is hosted by OASIS