cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <andrea.sm...@iona.com>
Subject Re: Schema namespaces and public URIs
Date Wed, 30 May 2007 14:32:16 GMT
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 <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"?

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


Mime
View raw message