> 1. In every xquery module file, since I almost always have > xpath-functions (fn:) as the default function namespace, I > also have to duplicate the module namespace in a its own > namespace declaration (in this case, the "t" namespace). > There's no way to avoid this boilerplate line of code?
You can define namespace prefixes through the admin UI, at the app server or group level. Then you don't need to define them in every file. > 2. Is it common to declare a variable for the no-namespace > (in this case, the "void" namespace), to use in places where > you're in a default namespace context and don't want to be? > (See the line poking the page title into the <title> element) I don't like defining a default namespace context, honestly, just to avoid this issue. > 3. Does it make sense to pass $content as an item()? Is it > too restrictive to specify $content as element(xhtml:div)*, > or even $content as element(div)* ? $content will almost > certainly be some xhtml structure, rather than a one-line string. I don't think you need to go all the way from element(foo) to item(). You could choose to stop at many points in between: element(), node(), etc. > 4. Any comments on the t:html function specifying it's return > type as element(xhtml:html)? This could also be > element(html), or even just element(). If it's what you mean to return, and you want the exception checking done, then it's good programming practice and will help you catch bugs. By definition, checking the return type of anything must take slightly more time than not checking it. But if your world is not based on milliseconds, this is not a real consideration. > 5. The xmlns="http://www.w3.org/1999/xhtml"; attribute in the > html element -- I know it puts itself and all children into a > default namespace (in this case, the xhtml namespace), but > what does this actually do for me? My guess is...if I remove > that, then the return type of the function should become > element(html) (or element()), and the fact that IE6 renders > everything properly in that situation, and FF displays the > DOM tree, means this has something to do with > xdmp:set-response-content-type being application/xhtml+xml vs > text/html. > I didn't show this above, but I have code similar to what > cq does in terms of checking if > xdmp:get-request-header('accept') contains > application/xhtml+xml, and if so, uses > xdmp:set-response-content-type to set the content-type to > application/xhtml+xml, rather than text/html. I believe you should type the elements correctly for this context, but can't put my hands on a simple cogent argument as to why. (ie. it's long since become practice for me, and I can't remember why :-) ) I'll leave it to others to tackle #5 and #6. ian _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
