Doesn't this allow for misalignment between the two Specs that could
lead to having two different versions and implementations of Maps?
Will we need to be aware of "XSLT maps" vs. "XPath maps" and study
these separately?
We're working hard to ensure that it's one specification, present in both
publications. As issues are resolved (e.g a recent one concerning the role of
the implicit timezone in matching keys in maps), the resolution is applied to
both specs.
Will anything make it obligatory for an implementor of XSLT 3.0 to
replace the XSLT maps with XPath maps at a future date, when XPath 3.1
becomes a recommendation?
Unless we screw up completely, replacing XSLT maps with XPath maps is a no-op.
Here is what I believe would be a good solution:
I. In case XPath 3.1 becomes Recommendation before XSLT 3.0, then XSLT
3.0 will remove the chapter on Maps and refer to XPath 3.1
I'm sure that's what we would do.
2. In case XPath 3.1 becomes Recommendation after XSLT 3.0, then a
3.1 version of XSLT will be published (or just a note maybe), that
will invalidate/remove the Maps chapter from the specification.
Hopefully this won't be necessary, but we can cross that bridge when we come to
it. As I said, the strategy is to keep our options open.
Michael Kay
Saxonica
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--