Issue with new validation scheme in HEAD

From: Ryan Lubke <Ryan.Lubke_at_Sun.COM>
Date: Thu, 17 May 2007 08:32:16 -0700

Hey folks,

Yesterday I logged an issue against shale [1] to promote some discussion
on an issue that was found after changing the config/parse code in the
HEAD for _05.

Here is the details from the issue:


In order to portably support the validation of both DTD and Schema-based faces-config documents in the RI,
we've had to take the approach or transforming any 1.0/1.1 documents to 1.2 and perform schema validation
(there is no portable way to validate using both schema and dtd).

Doing so has brought up an interesting issue when deploying to a container when validation is enabled.

Consider the following shale managed bean entry:

  <!-- Default logging adapter implementation -->

This will fail to validate against the 1.2 schema with the following error:

(cvc-pattern-valid: Value 'org.apache.shale.remoting.LOGGER' is not facet-valid with respect to pattern '($|_|\p{L})(\p{L}|\p{Nd}|_|$)*' for type 'null'.)

I had talked to Craig off line about this. Here are his comments:

The spec language doesn't say anything, but the JSF 1.1 DTD comment regarding <managed-bean-name> includes the comment 'It must be of type "Identifier"', which references back to a "type description" above claiming that the content must conform to the syntax of a valid Java identifier. I suspect that, when this DTD was translated into a schema, this requirement was taken literally.

That creates an interesting backwards compatibility problem for Shale, but also an interesting spec question regarding backwards compatibility ... the RI for 1.2 is enforcing a requirement that the RI for 1.1 did not enforce, which could be argued is a breakage. But, in the mean time, I'm going to look at what the impact would be of correcting these names in Shale.

We haven't released these changes yet, so this has no immediate impact, but it would be good to get a discussion going on this and figure out what should be done.

For those of you on the EG, what do you think? Should the 1.2 schema be

At any rate, one possible solution that has been proposed is to create a
private 1.1 based schema
for validating 1.0/1.1 documents that doesn't impose the restriction on
the managed-bean-name element.

Thoughts? Comments?