W3C home > Mailing lists > Public > public-prov-wg@w3.org > April 2013

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

From: Stephan Zednik <zednis2@rpi.edu>
Date: Tue, 2 Apr 2013 13:56:51 -0600
Message-Id: <7B2A4AAB-4995-4102-9674-185142D6DF5C@rpi.edu>
Cc: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
To: Hook Hua <hook.hua@jpl.nasa.gov>, Curt Tilmes <Curt.Tilmes@nasa.gov>
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

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

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

- 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

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


> 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

Received on Tuesday, 2 April 2013 19:57:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:35 UTC