[jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Namespace handling [Was: Chapter 11: The JSF XML View Syntax]

Thu Oct 28 13:32:21 EDT 2010

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
>>
>