27069 2014-10-16 03:38:42 +0000 [XSLT30] Function signatures do not include namespace prefix 2015-10-29 09:50:39 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC Windows NT CLOSED FIXED P2 normal --- 1 abel.braaksma mike john public-qt-comments oldest_to_newest 113269 0 abel.braaksma 2014-10-16 03:38:42 +0000 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. 113280 1 mike 2014-10-16 08:06:02 +0000 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. 113281 2 john 2014-10-16 08:19:22 +0000 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. 113341 3 abel.braaksma 2014-10-16 17:27:32 +0000 > 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. 113352 4 abel.braaksma 2014-10-16 20:45:47 +0000 > 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. 113353 5 mike 2014-10-16 20:55:40 +0000 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). 113708 6 mike 2014-10-24 15:45:20 +0000 The stylesheet changes to achieve this are being tested.