Altova Mailing List Archives


RE: [xml-dev] ANN: xpath1() scheme for XPointer

From: "Keith W. Boone" <keith@---.--->
To: "Dare Obasanjo" <dareo@---------.--->,<michael.h.kay@--------.--->,"Elliotte Rusty Harold" <elharo@-------.---.--->,"Uche Ogbuji" <uche.ogbuji@-----------.--->
Date: 10/28/2002 6:59:00 PM
Dare, 
I suspect that the number of knowledgable people who have taken a look at the 2.0 data model is drastically smaller than those who have read and understand the 1.0 material.  The sheer size of the XPath 2.0 specifications is a limiting factor.  I suspect that there are a lot of people like myself who are interested, but don't have the time to read such a tomb.  I want 1.) with the ability to extend beyond the limitations.  XPath 1.0 is a good example of that kind of specification.
	
	Keith

Engineering is what happens when science and  
mathematics meet politics.  Products are what 
happens when all three meet reality.          

-----Original Message-----
From: Dare Obasanjo [mailto:dareo@m...]
Sent: Monday, October 28, 2002 1:25 PM
To: michael.h.kay@n...; Elliotte Rusty Harold; Uche Ogbuji
Cc: xml-dev@l...
Subject: RE: [xml-dev] ANN: xpath1() scheme for XPointer


That's a bad simplification. No one is debating short & ambiguous spec vs. long & detailed spec. 
 
Secondly, the data model is probably the only part of XPath 2.0 that doesn't have fundamental issues and seems to have received little (if any) complaint from any of the knowledgeable people who have taken a look at it. All in all, bad examples in your email. 
 
The question is really whether we want 
 
1.) Consistent and simple yet limited specs (lack of string manipulation functions in XPath is such a gross oversight)
 
or 
 
2.) Inconsistent and complex specs that try to be everything to everybody but fall far short (W3C XML Schema, possibly XQuery)
 
The interesting correlation is that the size of the working groups for both classes of specs are significantly different. 

	-----Original Message----- 
	From: Michael Kay [mailto:michael.h.kay@n...] 
	Sent: Mon 10/28/2002 10:18 AM 
	To: 'Elliotte Rusty Harold'; 'Uche Ogbuji' 
	Cc: xml-dev@l... 
	Subject: RE: [xml-dev] ANN: xpath1() scheme for XPointer
	
	

	> OK, since you asked for it, here are some of the sections of XPath
	> and XSLT specs which I think only make sense if you understand the
	> input tree to have a direct connection to the actual XML document:
	
	
	Perhaps I should ask for a vote: do people on this list prefer the
	simple 3-page James Clark description of the XPath 1.0 data model, with
	all these inherent ambiguities, or the complex 30-page committee-written
	description of the XPath 2.0 data model, which attempts to eliminate all
	such ambiguities by diving into layers of abstraction and formalism?
	
	I get the impression you lot can't make your minds up.
	
	Michael Kay
	Software AG
	home: Michael.H.Kay@n...
	work: Michael.Kay@s...
	
	
	-----------------------------------------------------------------
	The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
	initiative of OASIS <http://www.oasis-open.org>
	
	The list archives are at http://lists.xml.org/archives/xml-dev/
	
	To subscribe or unsubscribe from this list use the subscription
	manager: <http://lists.xml.org/ob/adm.pl>

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.