[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Recently published W3C Working Drafts (long)

• To: Joe English <jenglish@f...>, xml-dev@l...
• Subject: Re: Recently published W3C Working Drafts (long)
• From: Paul T <pault12@p...>
• Date: Thu, 20 Dec 2001 16:16:17 -0800
• References: <200112202258.OAA28095@d...>

0. I don't quite understand what you're talking about, 
because I thought that XPath 2.0 WD does not 
exist.  

http://www.w3c.org/TR/xpath points to 
XPath v 1.0 Rec and contains zero pointers 
to XPath 2.0 materials. 

I'm wondering, is that on purpose?
I mean that if going by 'XPath' link from w3c.org 
main page, nobody could guess that there is any 
work on XPath 2.0. 

If going by "XSL" link,  it will bring 
http://www.w3c.org/Style/XSL/
and that page has a pointer to 
http://www.w3c.org/TR/xpath20req

Am I right that when talking about  XPath 2.0 WD 
you're talking about

http://www.w3.org/TR/xquery-operators/ 
http://www.w3.org/TR/query-datamodel/
http://www.w3c.org/TR/xpath20req

If you have some other URL, related to 
XPath v 2.0 WD, I'd appreciate if you share it.

As to your question , which is, from my point of view
"does it make sense to have XPath and XQuery doing 
the same stuff?" , I should make 2 points:

1. This situation is the exact copy of the situation 
we had (have) with XSL FO and CSS
(both kinda 'do the same' and I should stress 
out  that I'm talking about the XSL FO, not 
about the XSLT or XSL! ). Correct
me if I'm wrong, but my impression is that 
in that situation ( and probably in the situation 
with XQuery / XPath) we  had (have)  2 big camps, 
each pushing their own solution, occasionally 
'synchronizing' their designs to some degree.

XSL FO and CSS got synchronized at some point 
in exactly the way XPath  2.0 is synchronized with 
XQuery. 'Synchronization without refactoring' is a 
style of W3C. Those, who write code for living, 
should have their opinion on this style.

2. I don't really know if in the 'conflict'
between XQuery  and XPath one or another 
'branch'  has any 'right to exist', because 
I think that those two big guys would 
join XSL FO / CSS guys on their way 
to nowhere.

Now some ... of course - questionable ...  idea 
and  maybe it is just a wrong idea, ... but whatever ...  

I think that what they've done to XPath 2.0 would result 
in slow and cumbersome engines that would be possibly 
implemented only by a few big companies and because 
XPath 2.0 requirements document (still)  has no word 
'update' in it, XPath alternatives would emerge next years.

I believe that XPath has to be refactored (current 'XPath' 
is better to be called 'XSelect' ) and I'm working 
on that right now. 

Those, who are interested in re-designing XPath so that 
it may become really 'XPath' ( The Path in The 'XML Three' ),
not the interpreter for string operations or god-knows-what 
they-will-put-in-it-in-version-3 are welcome to write me.  

Or we can discuss the possible XPath alternatives on this list, 
if that would not be offtopic.

I'm talking about some things like :

/some/path[condition]/(this-is-the-nodeset-i-want-to-get)/child[condition]

Like it is in perl regular expressions. 

The idea is that instead of migrating some parts of Perl or Java into 
XPath interpreter, one should give the clean and convinient API 
to transfer Chunks of XML ( Nodes, whatever ) to/from XPath
interpreter, so that people can use their existing languages, not 
learning the cumbersome ones. 

'Binding is the king'. Perl + DBI /  DBD beats any 4GL language 
e t.c. I see not a sign of this view in W3C WDs, just more 
magic words to learn every day. 

Now about the refactoring.

Well ... it is good that some individuals at W3C are now suggesting 
some refactoring of XML, such as  throwing out the DTDs.

If even refactoring of a holy cow of XML 1.0 is now 
considered a 'politically correct' statement, I should say 
that refactoring of XPath looks kinda .. unavoidable ...

Current XPath was plain 'XSelect',  because XSLT had no 
need in updates. Now they're 'fixing' XPath with placing more 
and more functionality into this ill-designed thing. Talk about 
the 'qwerty'  keyboard.

And you're now asking is it sane to have XQuery and 
XPath and XPointer. Of course it is not, it all should be 
refactored ( and it will be refactored, it will just take a 
long time ).

Sure,  I got something wrong and maybe I've made 
some politically incorrect statements again, but perhaps 
the very same statements would become politically 
correct after some time, so I don't really know if 
I should apologize for something I've said above.

Rgds.Paul.

----- Original Message ----- 
From: "Joe English" <jenglish@f...>


> 
> Now that XPath 2.0 has been expanded to include most of the
> features of XQuery (with the rest already in XSLT), is
> a separate query language really needed anymore?
> Will anybody ever be able to implement XPointer now?
> 
> But seriously, the new XPath and XSLT drafts look good
> to me at first glance (everything on my wish list made
> it in :-).  Looks like I've got some reading to do...
> 
> 
> --Joe English
> 
>   jenglish@f...
> 
> -----------------------------------------------------------------
> 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>
> 

• Follow-Ups:
  • Re: Recently published W3C Working Drafts (long)
    • From: Christian Nentwich <c.nentwich@c...>

• References:
  • Recently published W3C Working Drafts
    • From: Joe English <jenglish@f...>

• Prev by Date: Re: Goodbye to textual applications?
• Next by Date: Re: Xerces 2.0.0 - DocumentType.getInternalSubset() does it work?!
• Previous by thread: Recently published W3C Working Drafts
• Next by thread: Re: Recently published W3C Working Drafts (long)
• Index(es):
  • Date
  • Thread