[dsdl-comment] Comments on part 5 (DTLL)

Some comments (rather late I guess) on the draft
http://www.dsdl.org/dsdl-5.pdf

David

===================================================

2.
Normative references, currently include xslt2 (CR) but not
xpath 1 or xpath2 (which are both referred to extensively in the text)

7.2.1

> (Although it's legal to use ^ and $ to mark the
> beginning and end of the matched string, it's not necessary.)

If multi-line =true then ^ and $ don't just match the ends of the
strings. It needs to be clarified what happens in this case, is the
implicit anchoring the same as saying that ^ and $ are implicitly
added to the supplied regex (and so affected by the flag) or is the
implicit anchoring done by other means not affected by the flag.
I think the intention is that the regex always has to match the
whole string, in which case the reference to ^ and $ here is misleading.

Especially for the flag attribute case-insensitive you definitely need
a normative reference to xpath 2 (or perhaps more accurately XPath 2
F&O), this is by far the hardest flag to define, a lot of
complication is hidden in the casual example here that a matches A...
http://www.w3.org/TR/xpath-functions/#flags

* Does it matter that ignore-whitespace pertains to how the regex is
  interpreted;

I think all the flags can be interpreted as modifying the regex prior
to it being evaluated. ignore-whitespace causes whitespace to be lost
dot-all causes . to be changed to (.|\n) . case-insensitive cause [a-c]
to be changed to [a-cA-C] etc.

7.2.2
use of xpath 1 semantics forces you to invent processor-defined
elements as sibling of an artificial root node, cf saxon:tokenize or
exslt:tokenize. It would be far more natural to use XPath2 semantics
and return a sequence cf xpath2 tokenize(), this will also make
switching between XSD and RelaxNG/DTLL much simpler as XPath2 sequences
are explicitly designed to model XSD lists.

9.

drop $this or put it in the dtll namespace, (don't reserve names if it can be avoided.)

9.1
I think that the use of "." in compound names such as $this.red is
misguided, "." is used for
compound names in languages where it can't be used in the local name,
but it will lead to confusion here where
my.red is a valid property name.

9.2
don't reserve this and type

10.3
Suggest remove all these and allow xpath2 functions.

dt.property ?? (perhaps this one needs to stay?)

dt.if --> Xpath 2 if()

dt.default --> if(value) then value else default
(This seems a slightly odd function, what's its prototypical example?)

9.3
use xpath 2 types not xpath 1 (I know this means effectively using xsd types but so be it)
but basing the dtll model on xpath 1 (node set) semantics will become
increasingly problematic.
You need to refer to Xpath2 already for regex, and a suggestion in
section 5 that xslt2 extension functions might be used
xslt2/xpath2's XDM data model is completely different to that of XPath 1.
Backward compatibility is pretty good in practice, but relying on
backward compatibility is shaky ground for defining a new language, as
here.

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