2. This is confusing, because if you don't define default namespace
contexts when writing html, wouldn't it have to look like
declare namespace xhtml = "http://www.w3.org/1999/xhtml";
<xhtml:html>
<xhtml:head>
<xhtml:title>{ $options/void:title/text() }</xhtml:title>
</xhtml:head>
<xhtml:body>
<xhtml:div id="page">{ $content }</xhtml:div>
</xhtml:body>
</xhtml:html>
rather than having <html xmlns="http://www.w3.org/1999/xhtml";> at the
onset? I'm probably missing something here.
Thanks for the reply,
Eric
Ian Small wrote:
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
_______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
