Hi Dan,
comments inline ...
Dan Diephouse wrote:
Hi Andrea,
Sorry that I missed this message the first time around, Bo's recent
message
alerted me to it. Comments are inline...
On 5/22/07, Andrea Smyth <[EMAIL PROTECTED]> wrote:
Hi,
Before we release 2.0 Final (hopefully with cfg files etc. fixed so
that we can enable Spring schema validation:)) is an opportunity to
modify and bring consistency into namespaces and public URIs for the CXF
schemas.
Taking two schemas as an example, we have
Location:
trunk/rt/frontend/jaxws/src/main/resources/org/apache/cxf/jaxws/spring/jaxws.xsd
Target namespace: http://cxf.apache.org/jaxws
Public URI (as per spring.schemas):
http://cxf.apache.org/schema/jaxws.xsd
or
Location: trunk/tools/common/src/main/resources/schemas/wsdl/jms.xsd
Target namespace: http://cxf.apache.org/transports/jms
Public URI (as per spring.schemas):
http://cxf.apache.org/transport/jms.xsd
Right now, the schemas are not available at their public URI, but long
term they should be IMO, and therefore I'd like to see that
a) they use at least a common prefix, e.g. schema, after
http://cxf.apache.org/ to avoid clashes in d). The first example uses
"schema", the second uses no prefix at all, and yet others use "schemas"
instead of schema, see the concatenation of all spring.schemas files in
CXF below.
Are you suggesting that if a schema namespace is
http://cxf.apache.org/2.0/schemas/jms that should also be a publicly
available namespace? Or are you just suggesting we standardize on a
"schema"
or "transport" instead of "schemas" and "transports"?
No, here I was referring to URIs only, i.e. all schemas for 2.0 should
be located under the same root.
b) possibly include a version number or a date in the prefix, i.e.
schemas/2.0 or schemas/2007/06 (personally I find version numbers a bit
friendlier than dates; the version number need not be the same for all
schemas in a release, it would just happen to be so for the 2.0
release).
I would think version numbers would be more appropriate as dates won't
matter so much to users as versions will.
c) all cfg files consistently use these public URIs in their
schemalocation attribute
d) ideally we can make them available at their public URI
Right now this would have to be under http://incubator.apache.org/cxf/
but I assume that after graduation this will change to
http://cxf.apache.org. I we want to avoid a needless change upon
graduation, we could use http://cxf.apache.org in the public URI
already, and tell people that for now that can find any (public,
documented) CXF schema by substituting cxf.apache.org with
incubator.apache/cxf.
Ugh, that is a sticky one. I would prefer our URIs start with
http://cxf.apache.org/. Why don't I check in with infrastructure (or our
mentors) and see if we can get a redirect from
http://cxf.apache.org/schemas/foo.xsd to our incubator site for future
compatability.
I agree, URIs starting with http://cxf.apache.org/ are the only
realistic option. At best we can redirect right now, at worst the
schemas become accessible at their URIs only after graduation.
For reasons outlined below I tend towards not using a version number in
the URI, but instead adopt the convention that
http://cxf.apache.org/schemas/x.y contains the schemas for version x.y
and that http://cxf.apache.org/schemas/ directs to the current version.
As far as namespaces are concerned, we can use the same, a different or
no prefix - but whatever it is it should be used consistently. Using the
same prefix as in the URI is probably the simplest solution.
A version number or date in the namespace/public URI may look ugly, but
could prove very useful, especially as there is no such thing as "the"
big CXF schema, but lots of small schemas instead. And depending on the
evolution of their associated modules, they are more or less subject to
change in the future.
What do people think?
So I think all these changes are probably good things.
Are you also proposing that we move to one single namespace for
everything?
Or would we still have a JAX-WS namespace, a WS-A namespace, etc??
No no, I am just taking about http://cxf.apache.org/blah/foo.xsd to
http://cxf.apache.org/<prefix>blah/foo.xsd, where prefix is "", "2.0",
"schemas/2.0", or so.
Also, what about keeping the current namespace registrations around in
the
spring.* files so its easy for users to migrate to new versions. We
can add
a simple line to the AbstractBeanDefinitionParser to check the
namespaces (
i.e. does it start with http://cxf.apache.org/2.0/) and if not, emit a
deprecation warning.
Yes, this would be very helpful but at the same time using a prefix in
the namespace has wider impact:
For starters it's hard to determine the scope - should it be used only
in schemas that are used in cfg files, or in all schemas including those
defined in wsdl. Should it apply to schemas used for test/demo purposes
etc.
Then there is the question of whether or not to keep the prefix in the
package name for generated code - this can affect users, e.g. those who
are programmatically configuring their http conduits/destinations.
And of course it affects existing cfg files, wsdls, schemas...
And in order to parse 2.0 cfg files with 2.1 BeanDefinitionParsers we
not only need to register the parser for multiple namespaces, but also
register both old and new schema location in a spring.schemas files so
support validation.
My main concern really is for users to identify quickly if their cfg
files are still OK or what needs changing in them when they upgrade to a
new version.
But the above is a high price to pay, and I think validation alone may
be enough of a help. I would also like to keep it simple and deal with
only one version of namespaces and schema URIs in each version.
Say we have two beans in a cfg file that is valid for 2.1:
<beans ...xmlns:ns1=http://cxf.apache.org<ns-version-prefix>/ns1
xmlns:ns2=http://cxf.apache.org<ns-version-prefix>/ns2
xsi:schemaLocation="...
http://cxf.apache.org<ns-version-prefix>/ns1
http://cxf.apache.org/schemas<uri-version-prefix>/ns1.xsd
http://cxf.apache.org<ns-version-prefix>/ns2
http://cxf.apache.org/schemas<uri-version-prefix>/ns2.xsd">
<ns1:elem1 ..../>
<ns2:elem2 ..../>
</beans>
Now assume that in 2.1 the schema for ns2 had changed.
If ns-version-prefix or uri-version-prefix was "2.0" the cfg file
becomes invalid (The SAXParse exception will indicate problems with
schemas: ... no declaration can be found for element...).
If on the other hand both prefixes were empty, the file could be reused
provided the schema change is compatible, e.g. if an attribute was added.
For a non-compatible change, say an attribute type changes from
xsd:boolean to xsd:string a string, the cfg file would become invalid
but validation makes it easy enough to pinpoint the problem.
So overall my proposal would be:
1. No prefix in namespaces (close CXF-673).
2. Consistent use of version independent prefix "schemas" in URIs.
That way compatible changes will not require updates to cfg files.
3. To help users write validatable cfg files, publish the namespace -URI
mappings somewhere on the CXF wiki so users don't have to search for all
spring.schemas files and check their contents - a pain if they use
binary distributions. Having the schemas published in a location as
described above allows them to compare and get more help if the
validation error messages are not sufficient.
How does that sound?
Andrea.
- Dan
