[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    Re: Next features
From:       Wesley Leggette <wleggette () cleversafe ! com>
Date:       2009-04-16 18:49:55
Message-ID: C60CE803.B32F%wleggette () cleversafe ! com
[Download RAW message or body]




On 4/3/09 19:17, "Radu Preotiuc-Pietro" <radu.preotiuc-pietro@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-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]