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

Wed Oct 27 13:52:58 EDT 2010

On 10/27/10 9:37 AM, Ed Burns wrote:
>>>>>> On Tue, 26 Oct 2010 18:04:39 -0400, Andy Schwartz <andy.schwartz at oracle.com> said:
> AS> As such I don't believe that we need to add yet another element.
>
> This is fine and valid too.  However, I feel that if your root element
> is <html> then you should be calling your page XHTML, not XML.  In any
> case, what you have written above is certainly valid for a .view.xml
> file or .xhtml file.
>   

Great.  Not sure what the right terminology is, but as long as users of 
the Facelets XML-processing mode can continue to use plain old <html> 
elements instead of <h:html>, I am happy. :-)

> AS> BTW, one thing that I am not totally clear on... What value does 
> AS> <h:html> add over plain old <html>?
> EB> 
> EB> It's a resource target, in addition to rendering the <html> element.
> EB> 
>
> AS> Did we add a new resource target type?  Our head/body/form targets were 
> AS> already covered by the <h:head>, <h:body> and <h:form> components.
>
> The "resource target type" you refer to was always just a loose and
> arbitrary string that is equivalent to the QNAME of the element.  In
> that sense, we did add a new resource target type.  See the renderkit
> docs for javax.faces.Output javax.faces.Html
>   

I see.  Unfortunately this approach is flawed.  The <html> element may 
only contain <head> and <body> elements.  As such, "html" is not a valid 
target for resource relocation.  We need to remove this new requirement 
from the 2.1 specification.

If <h:html> cannot serve as a resource target and if <html> is a valid 
element in XML processing mode, I am still unclear on the value of 
<h:html> and wonder whether this should be included in the 2.1 
specification.

On a related note, what's up with <h:title>? :-)  Can we kill this off?  
Or is there some reason why folks would need to use this instead of <title>?

> EB> Yes, I read Dan's initial comments but decided to go with the minimal
> EB> set you have seen in the design thus far.  So, I'll not be introducing
> EB> <f:doctype> in this revision.
>
> AS> Does this mean that we will not render any doctype for XML-style views?
>
> The initial requirements for what passes through and what does not,
> which went into Appendix A table 1-1, didn't say anything about DOCTYPE.
>   

Oh, woops.  Dan called this out in his initial "Facelets is XML" email:

> 3) All markup declarations should be produced by the component tree 
> (e.g., XML declaration, doctype, namespaces, CDATA, XML comments, etc)

However, I must have glossed over this in our recent exchanges.

> XML-wise, DOCTYPE is not a processing instruction, CDATA, or comment.
> Therefore, it passes through unchanged.  Do you think we need to
> explicitly address doctype in Appendix A table 1-1?
>   

Yes.  The problem, which Cay described yesterday, is that the doctype 
that is specified inside of the Facelets page is currently serving 
double duty.  In our legacy xhtml-mode, the doctype is applied both the 
generated content, as well as for the Facelets document.  The latter is 
undesirable, since it leads to validation/tooling problems.  We need a 
way to specify the doctype for the generated content without misleading 
tools into thinking that our Facelets document should comply with the 
xhtml document type.

Unfortunately, this gets us back to the need for an f/h:doctype component.

Andy