366 xsl:package-location

[Arithmeticus]

First draft, for initial feedback.

Notes:

• Because the CG has little energy/resources to develop the EXPath Zip module, I have situated the question of archive (compressed or not) in the URI scheme itself. There are dozens of archives, dozens of URI schemes. The only case where I have found overlap is in the jar: scheme/archive. Yes, I've seen zip: used as an alias for jar:, but it's not an official IANA URI scheme. This may need discussion.
• I have opted to bind @priority to a non-zero integer. This is the first time the constraint for the union of positive and negative integers has been placed on an XSLT attribute, so I may not have correctly set up element-catalog.xml.
• I have opted to not make attribute values format, name, and version as criteria for the priority package location (new term), so that developers can be warned when the package is at odds with the declaration. To make them criteria would mean that inconsistencies between the declaration and the referenced packages would remain undetected.
• I adopted the terms "URL" and "entry" based upon the IANA nomenclature for the jar: scheme.
• I may have overthought the distinction between archive and non-archive URIs. Feedback is appreciated.
• Error code 3000 has been broken up into different possible errors.
• Suggestions on the type and number of tests that need to be written for the test suite are welcome.

[michaelhkay]

3.5.3

If two or more [xsl:package-location]declarations have the same priority value, a static error is raised.

• Specify sibling xsl:package-location declarations. Ditto in ERR XTSE3002. Technically, this isn't a declaration as defined in 3.7, but I think that's OK so long as we don't hyperlink it).

For a package location to be accepted as a priority package location

Additional condition: the value of @format must either be "xslt", or absent, or a value recognised by the implementation. i.e declarations with an unrecognized value of @format are ignored.

file

The word "file" is widely used throughout the new text. I think more common W3C practice is to use "resource". And a URI doesn't "point to" a resource, it is dereferenced to deliver a resource. I think in the general case you should identify that the resource is an archive by means of the media type in the HTTP response, not by the URI scheme used to fetch it. In any case, if the package is in a local JAR or ZIP file, it's going to use the "file" URI scheme, and you're going to use either the file extension or peeking at the initial octets to identify it as an archive.

We need a note somewhere that the URI in the href attribute, after resolving as described in 5.9, may be dereferenced via an indirection mechanism such as a user-supplied URI resolver or catalog.

I'm wondering also whether we should make explicit provision for resolving using the combination of a repository URI (e.g "maven central") and an artefact ID within that repository. Perhaps just add an @artefact attribute (or is it "artifact" in en-US?) and say that the href attribute may identify a repository within which the package can be located, and the artefact attribute identifies the package within that repository.

[michaelhkay]

It might be simpler to allow any priority value, and to say that if the priority is >= 0, the location is used in preference to any implementation-defined location, while if it is <=0, it is used only as a fallback when implementation-defined mechanisms fail. It might be worth spelling out that for priority, a high number represents a higher priority than a low number (since the opposite convention is in common use).

[michaelhkay]

Suggestions on the type and number of tests that need to be written for the test suite are welcome.

I think the main thing is to exercise all the syntactic options. Tests in this kind of area tend to be difficult for a number of reasons: (a) some of the detail tends to be implementation-defined, (b) it's easy to end up testing the test driver rather than testing the product, (c) we don't have a reliable way of accessing HTTP resources from tests. Just do the best you can!

[michaelhkay]

Given that JAR file URIs are not really standardized, I wonder if they too should be handled by a pair of attributes, one identifying the container, and the other the specific artefact within the container.