Saxon

As a related question, what is the correct syntax to specify saxon:attribute-order="a b c * xml:space" in the second parameter (map) of fn:serialize()? It seems to reject * for a reason similar to annotatedConfig.xsd.

Thanks for pointing out the omission.

Also applies to config.xsd.

Both defer to saxon-atributes.xsd for the atttribute definition, which refers back to config.xsd for the type definition (this is itself a bit questionable since it means we duplicate definitions between annotatedConfig.xsd and config.xsd -- I'm really not sure why we have both).

We need to use a new type listOfQNameOrWildcard type in place of listOfQNameType, defined as a (list of (union of(QName, string with enum="*"))).

(By the way, it's great to know that there are users visiting obscure corners of the product like this one, and telling us when they hit problems).

Can you shed some light on this?

As a related question, what is the correct syntax to specify saxon:attribute-order="a b c * xml:space" in the second parameter (map) of fn:serialize()? It seems to reject * for a reason similar to annotatedConfig.xsd.

T Hata wrote:

As a related question, what is the correct syntax to specify saxon:attribute-order="a b c * xml:space" in the second parameter (map) of fn:serialize()? It seems to reject * for a reason similar to annotatedConfig.xsd.

In the fn:serialize() function, currently a value supplied for saxon:attribute must be a sequence of xs:QNames. You are right, this is also a bug - it should also allow "*". So I think something like the following should work, but it currently raises an error.

serialize($v, map{'method':'xml', xs:QName('saxon:attribute-order'): (xs:QName('a'), xs:QName('b'), xs:QName('c'), '*', xs:QName('xml:space'))})

Adding xslt30extra test case -s:output-properties -t:attribute-order-004

It's a bit of a shame to complicate the type signature (it becomes union(xs:QName, xs:string)* which is only expressible using extensions)

But I can't immediately think of anything better. An array of two sequences perhaps? Or using some special QName as a separator? Perhaps even two separate serialization properties? None of these seems particularly attractive.

I've changed the logic for fn:serialize() so it accepts a sequence of (QName or "*"). Patch committed for 9.9 and 10.0. The problem with the schema remains open.

There are a number of problems to fix with config.xsd

(a) As mentioned, the type for saxon:attribute-order does not allow the "*" token.

(b) Several Saxon serialization properties are missing: saxon:canonical, saxon:property-order, saxon:single-quotes

(c) Properties that accept a list of QNames generally use the type listOfQNames. This is literally a list with item type xs:QName, which means that the lexical form does not allow a URIQualifiedName (Q{uri}local). But the configuration reader certainly accepts this format.

(d) We programmatically expand the file config.xsd to annotatedConfig.xsd. This contains a reference to saxon-attributes.xsd, which in turn contains a reference back to config.xsd (not annotatedConfig.xsd).