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

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.

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?
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