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

Re: Recently published W3C Working Drafts (long)

• To: xml-dev@l...
• Subject: Re: Recently published W3C Working Drafts (long)
• From: Joe English <jenglish@f...>
• Date: Thu, 20 Dec 2001 17:06:22 -0800
• In-reply-to: <005d01c189b4$b5b28a20$2cd0a340@paultx>
• References: <005d01c189b4$b5b28a20$2cd0a340@paultx> <200112202258.OAA28095@d...>

Paul T wrote:
>
> 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.

You can get to it from <URL: http://www.w3.org/TR/ >,
under the heading "Recently Published Working Drafts".
WDs for XSLT 2.0, XPATH 2.0, and XQUERY 1.0 were just
added today (20 Dec 2001).

> 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! ).

CSS and XSL-FO have very different architectures though.
CSS is all about annotating existing XML documents
with just enough presentation information to display them
in a Web browser (with support for other media like paper
added later), whereas XSL-FO is an XML representation
of an abstract model for typesetting documents (with support
for other media like Web browsers added as an afterthought).
There are some applications where XSL-FO is more appropriate
than CSS and vice versa.

With XQuery though, there's almost nothing in there that hasn't
been added to XSLT and/or XPATH (except perhaps the syntax, which
is rather more pleasant IMHO).


[...]

> 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]
>

ISTM something like this would be really useful for XPointer.
XPath 2.0 is *way* overkill.  I think a good approach would
be to start with TEI XPTRs and take stuff out.


--Joe English

  jenglish@f...

• Follow-Ups:
  • Re: Recently published W3C Working Drafts (long)
    • From: Paul T <pault12@p...>

• References:
  • Re: Recently published W3C Working Drafts (long)
    • From: Paul T <pault12@p...>
  • Recently published W3C Working Drafts
    • From: Joe English <jenglish@f...>

• Prev by Date: Re: Why would MS want to make XML break on UNIX, Perl, Python, etc ?
• Next by Date: Re: Why would MS want to make XML break on UNIX, Perl, Python, etc ?
• Previous by thread: Re: Recently published W3C Working Drafts (long)
• Next by thread: Re: Recently published W3C Working Drafts (long)
• Index(es):
  • Date
  • Thread