On 4/3/09 19:17, "Radu Preotiuc-Pietro" <radu.preotiuc-pie...@oracle.com>
wrote:
> Ahh, two more. That's good.
>
> In regards to forward compatibility. From what I have heard about XMLSchema
> 1.1, the approach they took is to relax the UPA rule so that it's no longer a
> conflict for a named element and a wildcard to overlap. That enables one to
> put extensibility elements at the end of the context and specialize them in
> later versions of the Schema. This is what I mean:
The main problem with all of the wildcard stuff is that it is generally
impossible to predict the future. This means that to get a fully compatible
system you must have wildcards everywhere, which makes it very difficult to
work with the Schema.
I'm a proponent of the "projection" validation model, and would like to
implement it in XMLBeans.
(another reference:
http://www.pacificspirit.com/Authoring/Compatibility/ProvidingCompatibleSche
maEvolution.html)
>
> As for having substitute URIs, you are probably aware of
> XmlOptions.setLoadSubstituteNamespaces (obviously no regexes). Would your
> proposed option act on the QNames as the document is loaded or act at
> validation level? I.e. if I get an XmlCusor over the doc, will I see 1.0
> namespace or 1.1? Other than that, seems an useful feature, even though, I'm
> thinking, if the Schemas really are forward- and backward-compatible, why not
> use the same target namespace? Then, you could add the version as an
> annotation.
With regards to this, I'm fairly convinced by your argument and will likely
take this approach (of not changing the target namespace) in our
applications. Thus, I will not bother implementing regexs or callbacks to
setLoadSubstituteNamespaces, as I no longer have a need for it.
I am still looking for the best way to indicate the Schema and/or document
version. There are several suggestions floating about, but I'm not
particularly convinced by any of them yet.
Wesley
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org
