[dsdl-comment] Re: Draft for Part 5

Dear all,
 
The XPath version question is obviously a biggie - so I will leave the current draft as-is and countries can make their comments in the ballot: the issue can then get properly examined in the BRM in WG1 in Prague 2009 (you'll all be there right? the meetings are build around XML Prague).
 
The PoC works okay for regexes (except they are Java flavoured; I need to nab the adapter code out of jing that Mike Kay also used in Saxon - unless somebody else has got a better idea). The XPath implementaion used in the PoC is Jaxen 1.1.
 
- Alex.

________________________________

From: dsdl-comment-bounce@dsdl.org on behalf of Rick Jelliffe
Sent: Tue 2008-09-30 17:19
To: dsdl-comment@dsdl.org
Subject: [dsdl-comment] Re: Draft for Part 5

David Carlisle wrote:
>
>
> 2008/9/29 Rick Jelliffe <rjelliffe@allette.com.au
> <mailto:rjelliffe@allette.com.au>>
>
>
> May I suggest doing what Schematron did, and making the expression
> language into a parameter of the stylesheet?
>
>
> I think this would be a good idea, but in addition I think it would be
> good policy to refrain from adding extensions to xpath 1 that do
> conflict with xpath2, or potentially conflict with future versions of
> xpath.
>
> XForms has this problem, it added to the xpath 1 function library in
> ways that turned out to conflict with xpath2 when it finally appeared
> which makes migrating xforms to xpath2 harder than it would otherwise
> have been.
>
> The regex syntax added to xpath 1 here is almost but not quite that of
> xpath2, and I fear that difference will cause problems down the line.
> Having named regex groups rather than numbered ones is a slight
> cosmetic improvement, but absolutely no gain in functionality, and
> losing the ability to share code with XQuery/XPath2 regex systems is a
> high price to pay.
I don't think the regular expressions are added to the XPaths. Regexes
are used in two places in the draft: in <regex> and in detecting list
separators, not as extensions to Xpaths directly. I think if XSLT2 gets
positionals, and if they don't use the same syntax as everyone else,
that can be handled by adding markup to explicitly state which Xpath is
being used: as we have found before, waiting for W3C groups to finish
fast is just as time-wasting as them waiting for SC34 to finish things!
We have no guarantee that they will do anything, and as long as our
positional syntax is conservative and mirrors what popular
implementations already do, I think we are pretty safe.

David is correct that we need to look at implementability. I think the
following is the case:

1) Full implementation: XSLT2, with regex expression parsing before
evaluation (therefore a two-stage compilation since no eval() is
available AFAIK.)

2) Full implementation: XSLT1, with an extension function call to a
standard regex library, and possibly a regex rewrite function to cope
with the positional parameters.

3) Full implementation: EXSLT with regex library, with rewrite
functionality.

4) Full implementation: any programming language with an XPath library
that is really an XSLT1 library, and which has a regex library,
preferably one with named positionals.

5) Partial implementation: XSLT1. Does not support validation of list
or regex constraints: fail as "unknown" or generate provisional valid
with no false negatives.

5a) Full implementation: XSTL1 for some constraints, + program (e.g.
Java) with regex library for the rest.

6) Partial implementation: program with XPath1 library. Does not
support validation of list or regex constraints or paths with the
additional XSLT functions: fail as "unknown" or generate provisional
valid with no false negatives.

I don't think that is an unreasonable list, and it does not ring alarm
bells for me.

Personally I have pushed to avoid anything in Schematron that goes
beyond bog-standard XSLT1 to implement however the DTLL clearly
requires regexes, and I think named regexes are clearly desirable from
many POVs, which justifies their use. Unfortunately that rules out
unextended XSLT1 and XPath1; and perhaps it would cause problems for
JavaScript implementations too.

I certainly don't like the idea of standardizing anything that does not
have a pretty complete proof-of-concept implementation: what is the
status of the DTLL implementation prototype at the moment?

Cheers
Rick

--
DSDL comments
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-comment-request@dsdl.org
(mailto:dsdl-comment-request@dsdl.org?Subject=unsubscribe)

--
DSDL comments
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-comment-request@dsdl.org
(mailto:dsdl-comment-request@dsdl.org?Subject=unsubscribe)