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:
Base Schema:
<xs:complexType name="personType">
<xs:sequence>
<xs:element name="first-name" type="xs:string"/>
<xs:element name="last-name" type="xs:string"/>
<!-- extensibility -->
<xs:any namespace="##targetNamespace" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
Extended Schema:
<xs:complexType name="personTypev2">
<xs:complexContext>
<xs:extension base="personType">
<xs:sequence>
<xs:element name="age" type="xs:int"/>
<!-- further extensibility -->
<xs:any namespace="##targetNamespace" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
(I also belive there is some new syntax to automatically say that a type has
the <any> at the end.)
In XMLSchema 1.0, this would be an error, because the content of the extended
type would be (first-name, last-name, any*, age, any*) and the first "any*"
would collide with "age" and the validator would not know which one to match
against. XMLBeans has a mode (passing -noupa on the command line) where the
Schema would be allowed to compile, however if one tries to validate an
instance of "personTypev2", it would not work correctly because the rule
according to which an element particle takes precedence over a wildcard is not
implemented in the validator.
First of all, it would be nice to confirm that this is how things stand indeed
in XMLSchema 1.1 (and I can take this on) and then it would be good if we could
support this in XMLBeans. It would be better, IMO, for both XMLBeans and for
Schema authors, to move toward a solution that's likely to be in the future of
XMLSchema. I don't think it's a big change to the XMLBeans validator, but it is
tricky code (in SchemaTypeVisitorImpl). It would be at least worth it to give
this a thought and a short look at the code.
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.
Radu
> -----Original Message-----
> From: Wesley Leggette [mailto:wlegge...@cleversafe.com]
> Sent: Thursday, April 02, 2009 12:34 AM
> To: dev@xmlbeans.apache.org
> Subject: Next features
>
> Okay, so here are two more features that I would like to
> implement. I would appreciate any comments as to their
> viability and the best approach to start.
>
>
> 1. Projection Validation
>
> To support schemas with forward compatibility it is often
> desirable to specify that attributes and elements that are
> undefined in the schema are ignored rather than causing an
> error. However, you would generally still like to validate
> all options that are known.
>
> I'm getting this idea from:
>
> http://davidbau.com/archives/2003/12/01/theory_of_compatibilit
> y_part_1.html
> http://davidbau.com/archives/2003/12/08/theory_of_compatibilit
> y_part_2.html
> http://davidbau.com/archives/2004/01/15/theory_of_compatibilit
> y_part_3.html
>
> Here, Bau calls this "projection", in that a elements of a
> given input are "projected" onto the understood elements.
>
> It is possible to accomplish this with XmlBeans as it stands
> today. You:
>
> A. Validate with an error listener
> B. Obtain a cursor over the document
> C. Enumerate the cursor, deleting any elements mentioned in the
> error listener as "unknown" attributes or elements.
> D. Then, if any outstanding errors are left, you know the
> document is not valid.
>
>
> What I would like to add is a validation option called
> something like "VALIDATE_LAX_PROJECTION" or some such that
> has the validator (a) still pass the document if it contains
> unknown elements but all known elements are valid and (b)
> removes the unknown elements from the document (although this
> could be an additional option, whether the validation would
> remove the elements or simply keep them there?)
>
>
>
> 2. Regex Compatibility Urls
>
> In line with the above, I'd like to create schemas as follows:
>
> http://example.com/document/type/1.0
>
> Where 1.0 would be my supported document type, and any document
> matching:
>
> http://example.com/document/type/1.(.*)
>
> Pattern.compile("http://example\\.com/document/type/1\\..+";)
>
> Would be treated as a 1.0 document. This means that any
> elements added in the 1.1 schema would be ignored. This works
> as long as we use an compatiblity contract that says that (a)
> elements will not change in meaning between minor versions
> and (b) new elements will not affect the semantics of
> existing elements.
>
> It would seem one would need more (e.g., the ability to
> specify numbers greater than or equal to some thing), but
> when combined with a proper use of projection and the other
> concepts highlighted in the referenced articles, generally
> one would need only to implement a single version (1.0, 1.1,
> etc.) and be able to successfully project any document into
> an understood subset.
> Of course, more advanced matching could be provided if one
> didn't just use regular expressions, but that might make
> things overly complicated. Of course, another approach is
> allow a compatibility mapping callback to be provided in the
> XmlOptions. This would serve the same purpose but probably a
> bit more flexibly.
>
>
> Wesley
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org
> For additional commands, e-mail: dev-h...@xmlbeans.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org
