This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Probably editorial. In XP30 it is customary to use the namespace prefix in the function signature. Esp. now that we have functions both in the map and in the fn namespaces, I think we should include the prefix in the signature as well (plus it makes auto-generating a list of functions from the XHTML easier). I.e., we have: contains($map as map(*), $key as xs:anyAtomicType) as xs:boolean which looks much like fn:contains, but is actually map:contains.
I'm reluctant. Partly because of the sheer amount of work and the inevitability of errors (it can be automated for isolated references to functions, but not for function calls within example code), and secondly because I don't think it's a coding style I want to encourage. It just clutters the code and makes it less readable. The default function namespace in XSLT is always the fn namespace, so using the prefix is always redundant.
Abel wrote: ... (plus it makes auto-generating a list of functions from the XHTML easier)... Having gone through a similar process when generating info for our streamability analysis tool, where some of the tables in XSLT3.0 Section 19 were consulted semi-automatically, I'd rather encourage more use of attaching information to declarative structures such as the function catalogs and publishing them more systematically for such downstream purposes.
> and secondly because I don't think it's a coding style I want to encourage Sorry, I think you misunderstand. It is not about coding style, it is about the signatures of the functions. Not about examples, but about aligning those signatures (one place for each function, either "fn:" or "map:") with the way they are defined in FO30. Similarly, we use map functions always with the map prefix (I believe it is not even allowed otherwise) and currently we define it normatively without the map prefix. While not wrong per se, it seems a bit at odds at least.
> I'd rather encourage more use of attaching information to declarative > structures such as the function catalogs and publishing them more > systematically for such downstream purposes. (a bit OT) Well, it is a two-step process, where a controllable converter takes an offline XHTML document and turns it into an XML list of functions. It is not perfect, but the XHTML is well structured and there is little chance for change. The XML list of functions is small, clean and tidy and can henceforth be used at a plethora of occasions. Currently, I agree, this can be done more structurally and in one place, and I'll probably do so in the near future.
If you go into the CVS source, there is a function-catalog.xml which has all the function data in structured form. (In fact there's one for the F+O functions and another for the XSLT functions).
The stylesheet changes to achieve this are being tested.