[
Lists Home |
Date Index |
Thread Index
]
From: "Joe English" <jenglish@flightlab.com>
> > 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).
Oh, thank you! Maybe you know some w3c mailing list
where they announce such an important papers?
> > 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.
Maybe long time ago that was very true, but every year they
got closer and closer to each other.
> 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).
Yes, there is some difference between CSS and XSL FO,
but they share a significant bulk of properties / objects and also
recent CSS proposals got some stuff ... You know that
one can actually render some subset of XSL FO into plain CSS?
I'd suggest to check out the demos on www.renderx.com
website, they have some demonstration on this issue.
> There are some applications where XSL-FO is more appropriate
> than CSS and vice versa.
Sure, but I'd not say that there is significantly more difference between
XSL FO and CSS than between XPath and XQuery.
> 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).
I'm sure some XQuery expert would be glad to
exlain us why XQuery is very much different from
XPath ... I remember XSL FO experts explaining
why FOs are very much different from CSS ...
However, if replacing <DIV class='my-formatting-object'>
with <xsl:my-formatting-object> one may realize that
for many cases it just does not matter do you invoke
the renderer with the help of first form or with the
second form. Kinda 'different syntax for the same stuff'...
Also consider recent CSS proposals about
page layouts ... they were 'recent' like ...
one year ago ... (?)
>
> [...]
>
> > 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.
Can you please give me the good URL for
TEI XPTRs, because google returns some
messy stuff, like
http://www.tei-c.org/Vault/ED/edw68.htm
and I feel strange ... Maybe there is some
'complete' paper somewhere?
By the way, as far as I know, XPath is a subset
or XPTRs and they both are addressing thom
'the current point' - that's what I want to avoid,
because it complicates many things ( ' just one more axis'
*is* a complication of things from my point of view )
The sample 'regexprs-alike' addressing that
I provided above ( with 'flexible hot-spot' instead of
hardcoded 'current' hot-spot), should allow to get
rid of 'ancestor' axis ... Also I want to eliminate
tricks similiar to mask1 | mask2, because it complicates
things ... e tc. I mean that what I want is the real
'worse is better', supporting 80% of XPath queries,
but in much simpler way than current XPath
( which is 'the right thing' ) does. C instead of LISP.
As usual.
I agree that XPTRs are worth looking at.
Rgds.Paul.
|
