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

Comments below.

--Stephan

On Apr 2, 2013, at 2:25 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote:

> Hi Stephan,
> Thanks for still looking into a solution for this issue, and summarizing the options.
> 
> May I suggest option 1.5.
> 
> a) keep use of abstract element and substitution,
>     but in FAQ, add an xml processing step, that inserts all included files in a single one,
>     and replaces the abstract element with the concrete ones.
> 
>     With this, you keep the modularity, but offer a JAXB way of handling it.

I like this idea.

> 
> b) introduce a mechanism to support any non prov element.
>     I am not sure what the right option is.
> 
> I think this option is not as radical as your option 1.
> 
> 
> An option for xsd:any not discussed yet I think  is to introduce a new element:
>     <prov:others>
>           here, xsd:any non-prov element 
>     </prov:others>
> 
> Thoughts?

I had forgotten about this suggestion.  At first thought I think it might work.

It seems like a reasonable compromise.

We will need to make slight modifications to the note, our examples, and possibly the primer.

> Luc
> 
> On 02/04/13 20:56, Stephan Zednik wrote:
>> 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
> 
> -- 
> Professor Luc Moreau
> Electronics and Computer Science   tel:   +44 23 8059 4487
> University of Southampton          fax:   +44 23 8059 2865
> Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
> United Kingdom                     http://www.ecs.soton.ac.uk/~lavm
>