You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xmlbeans.apache.org by David Jencks <da...@yahoo.com> on 2007/09/02 17:36:14 UTC
Re: Wildcard matching rule for XML namespaces?
AFAIK there's no wildcard support but there is support for swapping
known namespaces when you read a document.
private static Map<String, String> NAMESPACE_UPDATES = new
HashMap<String, String>();
//load the map somehow
XmlOptions options = new XmlOptions();
options.setLoadSubstituteNamespaces(NAMESPACE_UPDATES);
XmlObject parsed = XmlObject.Factory.parse(element, options);
If you want to pursue wildcards I'd look for what happens to this map
in the xmlbeans code. I think that its fed into the STAX layer:
OpenEJB does something similar with something that just plugs into STAX.
hope this helps
david jencks
On Aug 31, 2007, at 12:57 PM, Oliver Newell wrote:
>
> Hi - I'm working with a set of schemas that embed numbers of the
> form $major.$minor in the XML namespaces to convey version
> information. The numbering scheme extends to the imported
> namespaces - not just the target namespace of the schema, as shown
> below. By convention, minor numbers are used to indicate changes
> that are backwards compatible with previous versions - /additions/
> to the schema. Major numbers are incremented when changes are made
> that break backwards compatibility.
> <?xml version="1.0" encoding="UTF-8" ?>
> <WMS_Capabilities xmlns="http://www.opengis.net/wms/1.3"
> xmlns:gml="http://www.opengis.net/gml/3.1" >
> <Service>
> <Name>Web Map Service</Name>
> <KeywordList>
> <Keyword>Topography</Keyword>
> <Keyword>Contour</Keyword>
> </KeywordList>
>
> etc.....
>
> </Service>
> </WMS_Capabilities>
>
> I am interested in having the capability for XMLBeans-based
> applications to happily consume instance documents that are
> produced using new minor versions of a schema. I also want to only
> generating new package names for new major versions of the schema.
> I see there is a facility in the XMLBeans configuration mechanism
> to specify the package names that are generated, so I can do the
> latter. I don't see a way to do the former - it seems like some
> kind of a wildcard mapping rule is needed so that an application
> based on version 1.3 of a schema will know how to unmarshall a
> version 1.4 instance document to the 1.3 data model. In other
> words, a configuration rule that stated something like:
>
> http://www.opengis.net/wms/1.* --> mapsTo --> http://
> www.opengis.net/wms/1
>
> so that all versions with major number of 1 map to the same
> namespace as far as XMLbeans is concerned.
>
> The usefulness of the wildcard capability wouldn't be limited to
> the particular $major.$minor numbering approach shown above. It
> should also be capable of supporting some of the W3C namespace
> versioning practices (which tend to embed a year in the namespace).
> This capability would allow for significantly increased system
> agility as schemas evolve. Right now, if I bump a minor version
> number in a schema namespace, I have to make sure ALL XMLBeans
> consumers are updated to use the new namespace, which isn't very
> practical for the distributed, 24/7 systems we are working on.
>
> Is there an existing way to accomplish what I am describing in
> XMLBeans? If not, is there any developer interest, or can someone
> give me a hint as to how hard this would be to implement? (and
> where to start?)
>
> Thanks!
>
> -Oliver
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
Re: Wildcard matching rule for XML namespaces?
Posted by Oliver Newell <ol...@LL.mit.edu>.
Hi -
I was successful in implementing the behavior I was after. Attached is
an implementation of a WildcardMatchMap class that allows for mapping of
multiple keys that match a given pattern to a single common string. I
included some comments in the class header describing how it can be used
in conjunction with XmlBeans - basically identical to the steps David
provided. The upshot is that I can now set up my services that are based
on XmlBeans so that they still work when messages are received from
Service Clients based on newer versions of a service schema.
Thanks for the help!
-Oliver
Oliver Newell wrote:
> David - Thanks - that does help!
>
> Maybe I can just create a suitable WildcardMatchMap<String,String>
> object that conforms to the Map interface? I'll give that a shot and
> post on success :-) (or failure :-( )
>
> -Oliver
>
> David Jencks wrote:
>> AFAIK there's no wildcard support but there is support for swapping
>> known namespaces when you read a document.
>>
>> private static Map<String, String> NAMESPACE_UPDATES = new
>> HashMap<String, String>();
>> //load the map somehow
>>
>> XmlOptions options = new XmlOptions();
>> options.setLoadSubstituteNamespaces(NAMESPACE_UPDATES);
>> XmlObject parsed = XmlObject.Factory.parse(element, options);
>>
>> If you want to pursue wildcards I'd look for what happens to this map
>> in the xmlbeans code. I think that its fed into the STAX layer:
>> OpenEJB does something similar with something that just plugs into STAX.
>>
>> hope this helps
>> david jencks
>>
>>
>> On Aug 31, 2007, at 12:57 PM, Oliver Newell wrote:
>>
>>>
>>> Hi - I'm working with a set of schemas that embed numbers of the
>>> form $major.$minor in the XML namespaces to convey version
>>> information. The numbering scheme extends to the imported namespaces
>>> - not just the target namespace of the schema, as shown below. By
>>> convention, minor numbers are used to indicate changes that are
>>> backwards compatible with previous versions - /additions/ to the
>>> schema. Major numbers are incremented when changes are made that
>>> break backwards compatibility.
>>> <?xml version="1.0" encoding="UTF-8" ?>
>>> <WMS_Capabilities xmlns="http://www.opengis.net/wms/1.3"
>>> xmlns:gml="http://www.opengis.net/gml/3.1" >
>>> <Service>
>>> <Name>Web Map Service</Name>
>>> <KeywordList>
>>> <Keyword>Topography</Keyword>
>>> <Keyword>Contour</Keyword>
>>> </KeywordList>
>>>
>>> etc.....
>>>
>>> </Service>
>>> </WMS_Capabilities>
>>>
>>> I am interested in having the capability for XMLBeans-based
>>> applications to happily consume instance documents that are produced
>>> using new minor versions of a schema. I also want to only generating
>>> new package names for new major versions of the schema. I see there
>>> is a facility in the XMLBeans configuration mechanism to specify the
>>> package names that are generated, so I can do the latter. I don't
>>> see a way to do the former - it seems like some kind of a wildcard
>>> mapping rule is needed so that an application based on version 1.3
>>> of a schema will know how to unmarshall a version 1.4 instance
>>> document to the 1.3 data model. In other words, a configuration rule
>>> that stated something like:
>>>
>>> http://www.opengis.net/wms/1.* --> mapsTo -->
>>> http://www.opengis.net/wms/1
>>>
>>> so that all versions with major number of 1 map to the same
>>> namespace as far as XMLbeans is concerned.
>>>
>>> The usefulness of the wildcard capability wouldn't be limited to the
>>> particular $major.$minor numbering approach shown above. It should
>>> also be capable of supporting some of the W3C namespace versioning
>>> practices (which tend to embed a year in the namespace). This
>>> capability would allow for significantly increased system agility as
>>> schemas evolve. Right now, if I bump a minor version number in a
>>> schema namespace, I have to make sure ALL XMLBeans consumers are
>>> updated to use the new namespace, which isn't very practical for the
>>> distributed, 24/7 systems we are working on.
>>>
>>> Is there an existing way to accomplish what I am describing in
>>> XMLBeans? If not, is there any developer interest, or can someone
>>> give me a hint as to how hard this would be to implement? (and where
>>> to start?)
>>>
>>> Thanks!
>>>
>>> -Oliver
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
>>> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
>> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail: dev-help@xmlbeans.apache.org
Re: Wildcard matching rule for XML namespaces?
Posted by Oliver Newell <ol...@LL.mit.edu>.
David - Thanks - that does help!
Maybe I can just create a suitable WildcardMatchMap<String,String>
object that conforms to the Map interface? I'll give that a shot and
post on success :-) (or failure :-( )
-Oliver
David Jencks wrote:
> AFAIK there's no wildcard support but there is support for swapping
> known namespaces when you read a document.
>
> private static Map<String, String> NAMESPACE_UPDATES = new
> HashMap<String, String>();
> //load the map somehow
>
> XmlOptions options = new XmlOptions();
> options.setLoadSubstituteNamespaces(NAMESPACE_UPDATES);
> XmlObject parsed = XmlObject.Factory.parse(element, options);
>
> If you want to pursue wildcards I'd look for what happens to this map
> in the xmlbeans code. I think that its fed into the STAX layer:
> OpenEJB does something similar with something that just plugs into STAX.
>
> hope this helps
> david jencks
>
>
> On Aug 31, 2007, at 12:57 PM, Oliver Newell wrote:
>
>>
>> Hi - I'm working with a set of schemas that embed numbers of the form
>> $major.$minor in the XML namespaces to convey version information.
>> The numbering scheme extends to the imported namespaces - not just
>> the target namespace of the schema, as shown below. By convention,
>> minor numbers are used to indicate changes that are backwards
>> compatible with previous versions - /additions/ to the schema. Major
>> numbers are incremented when changes are made that break backwards
>> compatibility.
>> <?xml version="1.0" encoding="UTF-8" ?>
>> <WMS_Capabilities xmlns="http://www.opengis.net/wms/1.3"
>> xmlns:gml="http://www.opengis.net/gml/3.1" >
>> <Service>
>> <Name>Web Map Service</Name>
>> <KeywordList>
>> <Keyword>Topography</Keyword>
>> <Keyword>Contour</Keyword>
>> </KeywordList>
>>
>> etc.....
>>
>> </Service>
>> </WMS_Capabilities>
>>
>> I am interested in having the capability for XMLBeans-based
>> applications to happily consume instance documents that are produced
>> using new minor versions of a schema. I also want to only generating
>> new package names for new major versions of the schema. I see there
>> is a facility in the XMLBeans configuration mechanism to specify the
>> package names that are generated, so I can do the latter. I don't see
>> a way to do the former - it seems like some kind of a wildcard
>> mapping rule is needed so that an application based on version 1.3 of
>> a schema will know how to unmarshall a version 1.4 instance document
>> to the 1.3 data model. In other words, a configuration rule that
>> stated something like:
>>
>> http://www.opengis.net/wms/1.* --> mapsTo -->
>> http://www.opengis.net/wms/1
>>
>> so that all versions with major number of 1 map to the same namespace
>> as far as XMLbeans is concerned.
>>
>> The usefulness of the wildcard capability wouldn't be limited to the
>> particular $major.$minor numbering approach shown above. It should
>> also be capable of supporting some of the W3C namespace versioning
>> practices (which tend to embed a year in the namespace). This
>> capability would allow for significantly increased system agility as
>> schemas evolve. Right now, if I bump a minor version number in a
>> schema namespace, I have to make sure ALL XMLBeans consumers are
>> updated to use the new namespace, which isn't very practical for the
>> distributed, 24/7 systems we are working on.
>>
>> Is there an existing way to accomplish what I am describing in
>> XMLBeans? If not, is there any developer interest, or can someone
>> give me a hint as to how hard this would be to implement? (and where
>> to start?)
>>
>> Thanks!
>>
>> -Oliver
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
>> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail: dev-help@xmlbeans.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org