@qt4cg statuses

The static context for (a) xsl:evaluate and (b) static expressions does not include the EXPath bin and file libraries. These should be included if these optional features are supported.

Fix #2801

Fix #2838

Fix #2825

Fix #2836

Adds a dm:location accessor in the data model and a corresponding fn:location function in F+O; a location is a four-part record containing system id, public id, line number, and column number.

Allows maintenance of location information to be requested in fn:doc, fn:parse-xml, etc.

Changes the diagnostics returned by xsd-validator to include a location record.

It seems to me that the function "decode-from-uri" is a misnomer. It probably arose because of a desire for symmetry with "encode-for-uri". But the reason that function wasn't named encode-uri is because the input isn't a URI; the encoding is done as part of the process of producing a URI from a non-URI. The reverse process, however, operates on a URI. "Decode" as an English verb takes the thing being decoded as a direct object, not an indirect object, so the semantically and grammatically correct name is "decode-uri".

I have identified a bunch of small issues with the XSD for XSLT. I would be happy to fix these and create a pull request, but I wanted to document them first in case there's any discussion required.

1. @main-module is missing from the XSD
2. xsl:item-type is missing from the XSD
3. @constructor is missing from the XSD
4. @merge-when is missing from the XSD
5. @component - the XSD is missing the values "item-type" and "record-type"
6. For xsl:field, the XSD allows a @required attribute but the spec doesn't allow it (already mentioned as an "Editorial Note").
7. xsl:record-type/@visibility - the XSD allows too many values, it should only be public/private
8. xsl:copy-of should not allow mixed content but the XSD allows it. (This appears to be a carryover from previous versions of XSLT.)
9. xsl:fork should not allow mixed content, should it?
10. The XSD doesn't allow "##any" for the [xsl:]xpath-default-namespace attribute
11. The XSD allows @json-node-output-method to have the values "json" and "adaptive" but they are not allowed by the spec
12. xsl:merge-source is missing the assertion that @type and @validation mutually exclusive (present on other elements)
13. The XSD allows an xsl:fallback child for xsl:mode, but the spec does not, should that be eliminated?
14. The base type of xsl:map and xsl:map-entry be sequence-constructor-or-select instead of sequence-constructor-and-select.
15. The type of xsl:when should be based on xsl:sequence-constructor-or-select instead of xsl:sequence-constructor.
16. Since version is required on xsl:package, an assertion should be added enforcing that it exists (similar to other required attributes)
17. xsl:record is in the XSD but not the spec? I supsect this part of the spec is in flux so would ignore this one for now?
18. @default-validation should not have a default value in the XSD because XSD validation implies adding that attribute if it is not present. If it were added with the default value during XSD validation it could potentially override a non-default value in a parent element. This may be pedantic because it is unlikely someone would validate the XSLT with the XSD and then run the transformation with the PSVI of the XSLT, but I think it is worth adjusting.
19. Similarly, the @override attribute on xsl:function should not have a default value because adding it during XSD validation could result in a value that conflicts with @override-extension-function, which would be a static error.
20. The @schema-role has a default value of "yes" in the XSD but that should not be there.
21. Missing default values. I'm of two minds about default values in XSD, but they are useful for documentation purposes and do exist in the current XSD for some attributes. However, there are a lot of missing ones. Presumably if the Element Syntax Summary in the spec lists a default value, it should be in the XSD?
22. xsl:apply-templates/@select has the default value "child::node()" in the XSD which I don't think is technically wrong but is not officially a default in the spec. I assume it should be removed to match the spec.
23. Similarly, xsl:character-map/@use-character-maps has a default of "" in the schema but not in the spec. I assume it should be removed to match the spec.
24. The documentation for the type "nametest" says "a list of nametests". really it's just a single nametest.
25. The documentation for the type "nametests" should say "EQName" instead of "QName".
26. The documentation for the type EQNames lists two uses of the type, but there are others. Maybe the "where used" info should be left out of the documentation for ease of maintenance.
27. The documentation for the type EQName-in-namespace should say "EQName" instead of "EQNames".
28. The documentation of fixed-namespaces-type says "A sequence of tokens, each of which may be one of #default, an NCName, ..." but that should be "#standard" not "#default".
29. The @normalization-form attribute could be more specifically defined. The XSD is sufficient for validation but not great for documentation.
30. The XSD is mostly in alphabetical order but "document" comes before "decimal-format".

The fn:validator function envisages that it should be possible to validate a document supplied as an XDM document or element node, and that the result of the function should include error information with associated line numbers.

But line numbers on nodes are not a recognized property in the data model, and furthermore, there is no way to request the line number of a node.

I suggest that we

(a) In XDM, recognize location as an optional property of a node. Location is of the form record(entity-uri, line, column).

(b) In the doc() and document() and parse-xml() functions, provide an option to request maintenance of location information in the constructed tree.

(c) Provide a function fn:location(node()) to return the information if it is available.

Given that we allow backslash-escaped whitespace characters in the indent-unit and line-ending serialization parameters, it seems odd not to allow them in item-separator. But doing so would be an incompatible change.

In most of the contexts where serialization parameters are specified, XML character references can be used to set their values. The main exception is in the $options parameter of the fn:serialize() function in pure XPath, where char('\t') can be used. Perhaps we should drop the ability to use backslash-escapes in indent-unit and line-ending?

Fix #2830

Essentially editorial, though it makes some technical decisions on the interaction of parameters such as line-ending and item-separator which may be non-obvious.

Closes #2263

Various of the comments in the issue were outdated. Worth discussing:

• Do we want record types for parameter types (specifically, fn:sort-by and array:sort-by)?
• Do we want to keep the rule alive that “all built-in record types live in the fn namespace”? Otherwise, we could change fn:array-sort-key-record to array:sort-key-record.
• I have skipped bin:infer-encoding as I didn’t know how to extend the record infrastructure to the EXPath modules.

Closes #2808

Closes #2809

I don't think the new spec is entirely clear about where (in the "phases of serialization") substitution of NL by CR or CRLF takes place. It's not mentioned at all in the "phases of serialization", and for the XML output method (which is the only one I've studied so far) it is covered only by a (non-normative) Note in §5.1.7. The note makes clear that the injected CR characters are not subject to character mapping, but it's not explicit that the don't get escaped as 
 or equivalent. The phrase "the characters that the serializer would otherwise emit" suggests that end-of-line substitution happens immediately after indentation and before encoding (because that's the last stage at which the serializer is emitting characters rather than octets). But this begs the question of where substitution of a literal CR in content by 
 takes place. For the XML output method the rule is given in the long introductory section 5 ("A consequence of this rule is that certain characters must be output as character references") but it doesn't say when this happens: I think we need to clarify that it is part of phase 3(e).

Suggestion:

(a) clarify that substitution of CR by 
 is part of phase 3(e)

(b) introduce a new phase between (4) and (5) to handle substitution of line endings.

I haven't looked at how methods other than XML are affected.