7:32 p.m.
>>>> On Thu, 04 Nov 2010 23:33:29 -0700, Ed Burns
<edward.burns(a)oracle.com> said:
>>>> On Wed, 3 Nov 2010 13:09:30 -0700, Ed Burns
<edward.burns(a)oracle.com> said:
EB> Hello JSF Expert Community,
EB> This is the fifth, and most likely final, iteration of the JSF 2.1
EB> spec. Please let's get this done so we can move on to JSF 2.2 and
EB> resolve all these nice composite component issues.
EB> Well, here's the sixth iteration. It has the improvements suggested by
EB> Andy.
EB>
https://javaserverfaces-spec-public.dev.java.net/files/documents/1936/153...
Imre Osswald, another excellent community member, grabbed me on IM this
morning and pointed out another little hole in the namespace solution.
This prompted me to make an edit to the PDF, which I have updated in the
above zip. If you downloaded it, download it again. It has a new pdf
but the rest is the same. Here is the commit message.
M integrationWithFacelets.fm
M preface.fm
M title.fm
- update date
- 10.3.2
add spec language that asserts that the root namespace must be passed
through unmodified.
The unprefixed namespace, also known as the root namespace, must be
passed through without modification or check for validity. The
passing through of the root namespace must occur on any non-prefixed
element in a facelet page. For example, the following markup
declaration:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<msup>
<msqrt>
<mrow>
<mi>a</mi>
<mo>+</mo>
<mi>b</mi>
</mrow>
</msqrt>
<mn>27</mn>
</msup>
</math>
would be rendered as
<html xmlns="http://www.w3.org/1999/xhtml">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<msup>
<msqrt>
<mrow>
<mi>a</mi>
<mo>+</mo>
<mi>b</mi>
</mrow>
</msqrt>
<mn>27</mn>
</msup>
</math>
I added an automated test to Mojarra to make sure this works and I do
indeed see the square root of a + b to the 27th when viewing the page in
Firefox with the necessary MathML fonts installed.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 3 work days until German Oracle User's Group Conference
| 10 work days until GlassFish 3.1 Hard Code Freeze
7:53 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] ANNOUNCE: JSF 2.1 Spec, Release Candidate Five
On 11/5/10 2:32 PM, Ed Burns wrote:
>>>>> On Thu, 04 Nov 2010 23:33:29 -0700, Ed Burns
<edward.burns(a)oracle.com> said:
>>>>>
The unprefixed namespace, also known as the root namespace, must be
passed through without modification or check for validity. The
passing through of the root namespace must occur on any non-prefixed
element in a facelet page.
Sounds good. (Sounds like we are just specifying behavior that Faclets
has always implemented, right?)
BTW, I see that we still have <h:html> and <h:title> components in the
latest spec. I haven't seen an explanation for why this are
necessary/useful. When I asked about this, you mentioned that <h:html>
was useful as a resource target. However, it is not. From our earlier
thread:
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>?
I don't remember seeing a response to this, though with all of the
emails lately, I may have missed it.
I still do not understand why our users would use <h:html> and <h:title>
over <html> and <title>. If we don't have a strong reason for why these
components are useful, we should remove these from the specification in
order to avoid spec/component bloat.
Andy
12:37 a.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] ANNOUNCE: JSF 2.1 Spec, Release Candidate Five
Just to chime in further on the continued presence of <h:html> and
<h:title>, as Andy said, in addition to just pointlessly bloating the
specification, having <h:html> act as a resource relocation target seems
just plain wrong.
-- Blake Sullivan
On 11/5/10 11:53 AM, Andy Schwartz wrote:
On 11/5/10 2:32 PM, Ed Burns wrote:
>>>>>> On Thu, 04 Nov 2010 23:33:29 -0700, Ed Burns
>>>>>> <edward.burns(a)oracle.com> said:
>
> The unprefixed namespace, also known as the root namespace, must be
> passed through without modification or check for validity. The
> passing through of the root namespace must occur on any non-prefixed
> element in a facelet page.
Sounds good. (Sounds like we are just specifying behavior that
Faclets has always implemented, right?)
BTW, I see that we still have <h:html> and <h:title> components in the
latest spec. I haven't seen an explanation for why this are
necessary/useful. When I asked about this, you mentioned that
<h:html> was useful as a resource target. However, it is not. From
our earlier thread:
> 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>?
I don't remember seeing a response to this, though with all of the
emails lately, I may have missed it.
I still do not understand why our users would use <h:html> and
<h:title> over <html> and <title>. If we don't have a strong
reason
for why these components are useful, we should remove these from the
specification in order to avoid spec/component bloat.
Andy
4929
days inactive
4929
days old
jsr-314-open-mirror@lists.jboss.org
2 comments
3 participants
participants (3)
-
Andy Schwartz -
Blake Sullivan -
Ed Burns