cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: Schema namespaces and public URIs
Date Wed, 30 May 2007 06:50:27 GMT
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 <andrea.smyth@iona.com> 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"?


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.

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

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.


- Dan



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message