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

Hi Stephan,

We use substitutionGroup="prov:internalElement" in both prov-dictionary and prov-links. So this approach would imply removing them there as well? Could you send either the updated xsds or generated JAXB *.java bindings?

Thanks,
Hook


From: Stephan Zednik <zednis2@rpi.edu<mailto:zednis2@rpi.edu>>
Date: Wed, 3 Apr 2013 11:25:52 -0600
To: "Hua, Hook (398C)" <hook.hua@jpl.nasa.gov<mailto:hook.hua@jpl.nasa.gov>>
Cc: "public-prov-wg@w3.org<mailto:public-prov-wg@w3.org>" <public-prov-wg@w3.org<mailto:public-prov-wg@w3.org>>
Subject: Re: ISSUE-648: Can schema be made a bit more jaxb friendly?


On Apr 3, 2013, at 11:16 AM, "Hua, Hook (398C)" <hook.hua@jpl.nasa.gov<mailto:hook.hua@jpl.nasa.gov>> wrote:

Hi Stephan,

Proposed solution (b) of <xs:complexType name="Others"> is an interesting one. Though it validates, do you still see JAXBElements in the generated JAXB bindings?

Did you try it yourself?

With prov:internalElement still in the document/bundle sequences you still get the JAXBElements in the generated JAXB bindings.  If you remove prov:internalElement, as we would suggest in the FAQ-entry, then you no longer get JAXBElements in the generated bindings.

--Stephan



--Hook


From: Stephan Zednik <zednis2@rpi.edu<mailto:zednis2@rpi.edu>>
Date: Tue, 2 Apr 2013 20:07:04 -0600
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk<mailto:L.Moreau@ecs.soton.ac.uk>>
Cc: <public-prov-wg@w3.org<mailto:public-prov-wg@w3.org>>
Subject: Re: ISSUE-648: Can schema be made a bit more jaxb friendly?
Resent-From: <public-prov-wg@w3.org<mailto:public-prov-wg@w3.org>>
Resent-Date: Wed, 3 Apr 2013 02:07:34 +0000


On Apr 2, 2013, at 2:25 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk<mailto: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..

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 made this update locally and all our example xml files still validate so we weren't using any non-prov elements at the document or bundle level (just as attributes) in our examples.  I will do a quick check to ensure that all examples in the Note are still valid but they were based on the xml examples in the repository so I expect that to be the case.

I propose we hold a straw poll  by email regarding adopting Luc's suggestions above so I can implement tonight and get the note staged for review (may go to stage early tomorrow morning).

PROPOSED:

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.

b) introduce a new element:

<prov:others>
          <!-- here, xsd:any non-prov element -->
  </prov:others>

to be implemented as:

<xs:element name="others" type="prov:Others"/>

  <xs:complexType name="Others">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
  </xs:complexType>

and the prov:others element to be referenced in the document and bundle sequences.

--Stephan

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<mailto:l..moreau@ecs.soton.ac.uk>
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm