ISSUE-648: Can schema be made a bit more jaxb friendly?

Hi Luc,

I've looked into ways to update the schema while retaining our current encapsulation strategy of having extension schemas uses substitution group elements on the prov:internalElement element and I have yet to figure out a way to do it.  I also have yet to figure out if we can provide a solution to improve JAXB binding without forcing all non-prov elements to be after the prov elements in document and bundle containers.

We are getting to the end of our timeframe for addressing this so we should make a decision ASAP.

Possible solutions:

1) implement the changes mentioned by Luc, which would be:

a) remove use of abstract element and substitution groups in prov-core and extension schemas
b) introduce ordering that requires xsd:any after prov elements in document and element containers

these changes would force us to also do the following:

c) remove include statements from prov.xsd and extension schemas, all schemas contain local declarations of prov core types
d) update the Note document to reflect changes

PROS: 
- Removes the JAXBElement.class type from the @XmlElementRef annotations in generated classes 

CONS:
- Removes our strategy for modularity and encapsulation in the schemas
- Restricts non-prov elements to only be valid after prov-elements in bundle and document containers

2) leave the schema and Note as they are; look into developing a separate JAXB-friendly schema which can be introduced in a FAQ entry.  Write FAQ entry about our experiences with JAXB binding irregardless of if a separate JAXB-friendly schema can be successfully developed.    

PROS:
- Increases our window to get the work done, we may not have determined the best solution yet
- Does not require a change to the existing Note or schema
- Allows us to introduce jaxb annotations in the FAQ schema that may help with the schema binding
- Preserves exiting modularity and encapsulation in the schemas

CONS:
- The JAX-friendly schema will likely need to be a more restrictive schema than the official schema (such as perhaps requiring xs:any elements outside of choices at the end of sequences), this may lead to problems in trying to unmarshall valid PROV-XML that does not conform to the JAXB-friendly schema.

3) Do nothing

I prefer 2) or 1) over not addressing this request.

--Stephan

> Hi 
> 
> I have ported the ProvToolbox and the ProvValidator to the new XML schema.
> I just wanted to report on my experience with the schema and JAXB.
> Obviously, others may have better experience with JAXB and may be able
> to help on some of the issues I encountered.
> 
> Everything worked fine, except:
> - <xs:element ref="prov:internalElement abstract=true/>
> - extensibility <xs:any namespace="##other"/> in Document and Bundle
> 
> 
> These two constructs, while processable by JAXB, are not JAXB-friendly.
> 
> Indeed, JAXB compiles the schema in a list containing all possible statements.
> 
> protected List<Object> entityAndActivityAndWasGeneratedBy;
> 
> However, the presence on an abstract element and an <any/> element result in the
> content of that list to be of type:
> 
> 
> @XmlElementRefs({
> @XmlElementRef(name = "used", namespace = "http://www.w3.org/ns/prov#", type = JAXBElement.class),
> @XmlElementRef(name = "wasAssociatedWith", namespace = "http://www.w3.org/ns/prov#", type = JAXBElement.class),
> @XmlElementRef(name = "person", namespace = "http://www.w3.org/ns/prov#", type = JAXBElement.class),
> @XmlElementRef(name = "entity", namespace = "http://www.w3.org/ns/prov#", type = JAXBElement.class),
> @XmlElementRef(name = "wasInfluencedBy", namespace = "http://www.w3.org/ns/prov#"
> ....
> })
> 
> @XmlAnyElement(lax = true)
> protected List<Object> entityAndActivityAndWasGeneratedBy;
> 
> where all data structures are wrapped up in this unpleasant JAXBElement.
> 
> Without these features, we get a much more natural mapping:
> @XmlElements({
> @XmlElement(name = "entity", namespace = "http://www.w3.org/ns/prov#", type = Entity.class),
> @XmlElement(name = "activity", namespace = "http://www.w3.org/ns/prov#", type = Activity.class),
> @XmlElement(name = "wasGeneratedBy", namespace = "http://www.w3.org/ns/prov#", type = WasGeneratedBy.class),
> @XmlElement(name = "used", namespace = "http://www.w3.org/ns/prov#", type = Used.class),
> @XmlElement(name = "wasInformedBy", namespace = "http://www.w3.org/ns/prov#", type = WasInformedBy.class),
> ...
> })
> 
> So, how I did I solve the problem? I inserted the extension schemas into the schema file, and hence got rid of the abstract element. I am ok with this. We could possible provide the utility to that transformation.
> 
> For the extensibility, I used a different definition. It happens to
> parse prov-xml compliant xml. When serializing, it puts all
> extensibility elements at the end. This is not a satisfactory
> solution, and is likely to be dependent of the jaxb implementation (though I am not entirely sure).
> 
> 
> <xs:complexType name="Document">
> <xs:sequence>
> <xs:choice maxOccurs="unbounded">
> <xs:group ref="prov:documentElements"/>
> <xs:element name="bundleContent" type="prov:NamedBundle"/>
> </xs:choice>
> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
> 
> Can something be done to make the XML schema a bit more jaxb friendly,
> while still keeping the same flexibility? Thoughts welcome.
> 
> Cheers,
> Luc