Re: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Namespace handling [Was: Chapter 11: The JSF XML View Syntax]
On 10/28/10 9:57 AM, Andy Schwartz wrote:
On 10/28/10 12:08 PM, Blake Sullivan wrote:
> I was thinking that this was an XHTML ResponseWriter thing. It's not
> like the ResponseWriter doesn't know that nobody has output a prefix
> mapping for XHTML yet (ignoring the case where it was sent out
> through unescaped text and even then creating a new mapping isn't the
> end of the world as long as it doesn't conflict).
Right. I think this would work well for simple use cases - such as
ensuring that the root <html> element ends up with the proper xhtml
namespace.
Should we consider more complex use cases, eg:
> <f:view xmlns:f="http://java.sun.com/jsf/core"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns="http://www.w3.org/1999/xhtml">
> <html>
> <h:head></h:head>
> <h:body xmlns="http://www.w3.org/2000/svg">
> <svg version="1.1" ...>
> <circle .../>
> </svg>
> </h:body>
> </h:head>
> </html>
> </f:view>
In this case, the Facelets compiler has some chance of figuring out
that the SVG namespace needs to be pushed down to the <svg> element.
By the time we get to the ResponseWriter, we have less information
available to us, and thus harder to correct arbitrary missing namespaces.
This is
where the ResponseWriter is being hosed by the lack of apis for
the namespace. In theory, the default Facelets tag handler should
always be passing a namespace to startElement. If that were the case,
the ResponseWriter would be called with:
startElement("svg", "http://www.w3.org/2000/svg") and the XML
ResponseWriter would realize that this isn't the current default
namespace and wait until the start element needs to be closed (in case a
default attribute was written manually) to add a default namespace:
<svg version="1.1" xmlns="http://www.w3.org/2000/svg">
With this scheme, we would always use the default namespace in the
ResponseWriter, so if we later had to output some HTML, the
ResponseWriter would write out the appropriate default namespace again:
<input xmlns="whatever the html namespace is">
If the output was constantly switching between namespaces, this would be
less efficient than having them all at the top, but it has the nice
advantage of not requiring foreknowledge. The only real tricky thing is
what to do if the page author wants to set the default namespace
themselves because they are about to blast out a bunch of raw content.
If it wasn't for that case, the ResponseWriter could essentially own the
default namespace itself.
However, these kinds of cases only show up when the output allows
multiple namespaces, which isn't pressing for the HTML use cases yet.
-- Blake
I don't know how much we care about solving this more generic case.
The xhtml namespace issue is clearly more pressing.
> We will eventually have a bigger problem that the ResponseWriter
> interface allows no way to specify a namespace. This is lame and I'm
> not a big fan of the workaround of abusing the default namespace or
> passing the prefixes in with the element names.
Agreed.
Andy
>
> -- Blake Sullivan
>