-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify support for XPath 4.0 or XSLT/XQuery 4.0 #70
Comments
The query language bindings are defined in normative annexes to the standard (I've been working on the XQuery ones just today). I think while the 4.0 specs are still in draft, we would have a hard time referencing them normatively in the Schematron standard. So I would say if implementers choose to implement 4.0 bindings at this juncture, that is a matter for them. But thank you @galtm for the reminder to reserve those binding values for future use, which I have now done in the latest working draft. I'll leave this open for now, in case circumstances change and while further technical changes to the draft are permitted. |
Thanks, @AndrewSales, for your reply and for reserving the 4.0 binding value for future use. As for the XSpec backdrop to my question, there is a way to test a Schematron schema that uses 4.0, but we can consider it experimental for now. |
First off, you can use any query language binding your implementation
provides, no matter whether they are in the standard or not.
The standard defines a set of standard query language bindings: so that
e.g. if you select "xslt2" as your QLB your implementation should provide a
QLB with whatever the standard specifies for that QLB (with the obvious and
usual caveat that where a standard QLB is vague or incomplete, the
implementation should do something sensible and useful, preferably in
concert with other implementators, preferably documented, and possibly
with a view to getting the gap in the standard filled-in.)
However, that in no way limits what non-standard or pre-standardization
QLBs that a Schematron schema can use. (I think most people would be
comfortable with the rule of thumb that experience is the best foundation
for a standard QLB, not speculation.) An implementation could allow Java
functions as a QLB for example.
However, the problem here is that xpath4 does not actually exist yet, as
far as I know. So it is not possible for an ISO standard to reference
something "normatively" before W3C (or whoever) has said what that thing
specifically is. What the ISO standard can do is reserve the names "xslt4"
and "xpath4" (if it does not already)/
ISO could possibly give a non-normative annex that gives the best guess of
the binding with the caveat that it might be superseded with a name like
"preview-xslt4" or whatever. (In particular, upgrading the Xpath to Xpath4
is trivial; the thing that can be tricky is whether XSLT4 has elements or
attributes that an "xslt4" QLB should demand. This is like how Schematron
needed an ***@***.*** to cope well with XSLT3 and probably XSLT2.)
So I suggest that anyone who is implementing changes to a Schematron engine
to make use of the "xpath4" features currently under discussion, or that
are in experimental SAXON implementations, should use a QLB name like
"draft-xpath4". That makes it's status clear.
After XPath4 is baked at W3C and available, then the implementer would be
safe to provide "xpath4" or "xslt4" with just the xpath4 features because
any standard QLB will have those; but I think if implementations allow
"xslt4" to access non-Xpath4 XSLT4 features before the ISO QLB is
standardized, they would be mislabelling the QLB (which kinda causes the
problem that having a QLB name is supposed to prevent.) If a user puts
"xslt4" in the QLB, and an implementation does not support the ISO standard
QLB (even a late draft) because the ISO QLB not baked, then the
implementation should tell the user "no, that is not a real thing" to
prevent the chances of false positives or negatives. Validation is one of
those things where you really do prefer certainty and strictness about this
kind of thing as the default operational mode of the validator, yes?
That is my idea of the way things should work, anyway.
Regards
Rick
…On Mon, Mar 18, 2024 at 2:21 AM Amanda Galtman ***@***.***> wrote:
Should I be able to use XPath 4.0 expressions in a Schematron schema, if
the underlying processor supports them? How about XSLT 4.0 or XQuery 4.0?
Would I use queryLanguageBinding="xslt4" or queryLanguageBinding="xquery4"
on the schema?
The XSpec repo has a feature request issue
<xspec/xspec#1729> about supporting 4.0 in
XSpec tests, but I didn't know if supporting 4.0 in XSpec tests for
Schematron schemas was supposed to be part of that task.
—
Reply to this email directly, view it on GitHub
<#70>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF65KKM2ULQTPUBHYIOBSH3YYWYIBAVCNFSM6AAAAABE2JLZEOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE4TANZSGAYTCNY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Should I be able to use XPath 4.0 expressions in a Schematron schema, if the underlying processor supports them? How about XSLT 4.0 or XQuery 4.0? Would I use
queryLanguageBinding="xslt4"
orqueryLanguageBinding="xquery4"
on the schema?The XSpec repo has a feature request issue about supporting 4.0 in XSpec tests, but I didn't know if supporting 4.0 in XSpec tests for Schematron schemas was supposed to be part of that task.
The text was updated successfully, but these errors were encountered: