Re: PROV-XML element ordering

Having explored the issue further I have determined that the the schema's use of references is not picked up at all by ORM tools and as such the OO classes will not reference each other in expected ways.

With the current schema the following xml can be marshalled

	<prov:entity prov:id="e1">
		<prov:label>entity-1</prov:label>
	</prov:entity>
	
	<prov:activity prov:id="a1"/>

	<prov:wasGeneratedBy prov:id="g1">
		<prov:entity prov:ref="e1"/>
		<prov:activity prov:ref="a1" />
		<prov:time>2001-10-26T21:32:52</prov:time>
		<ex:port>p1</ex:port>
	</prov:wasGeneratedBy>

but there will be no connection in the objects between g1 and either a1 or e1.

Usage of the JAXB generated classes would look like the following

// Generation g1 is generation object with id "g1"
QName ref = g1.getEntity().getRef();
// ... now find an Entity with id == ref

If we want the schema to play nicely with ORM tools than we will likely have to make major changes to the schema.  We may be forced to use xs:ID and xs:IDREF as the tools will actually be able to correctly interpret elements with type xs:IDREF as being a reference to another element in the document.  Even if we do, the Java type of the references will be Object because xml schema does not provide a way to define the range of a reference.

If we used changed prov:id to type xs:ID and prov:ref to xs:IDREF the following should work (assume non-choice prov:attributes so prov:label has a nice getter and setter method)

// Generation g1 is generation object with id "g1"
Entity e = (Entity) g1.getEntity().getRef();
Assert.true("entity-1", e.getLabel());

But we have already discussed xs:ID/xs:IDREF and determined that they are too restrictive.

So in conclusion, references and attributes do not work well with ORM tools in their current form.  I think references may be the bigger issue, because the ORM tools do not identify them as being references.  If there is a requirement now that the schema be constructed to work well with ORM tools it will affect more than just whether prov:attributes have a required order.

--Stephan

On Feb 6, 2013, at 8:08 PM, Stephan Zednik <zednis@rpi.edu> wrote:

> 
> On Feb 6, 2013, at 4:58 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk> wrote:
> 
>> Hi Stephan and Curt,
>> 
>> It is good to keep choice in documentElement.  You both introduced it. Let's not remove it.
> 
> I agree, but the choice in documentElement will lead to the same problem with JAXB that a choice in attributes does.
> 
> Both Document and Bundle classes generated by JAXB's xjc use a single list for all available elements in a documentElement.
> 
> The generated code looks like the following:
> 
>    protected List<JAXBElement<?>> entityOrActivityOrWasGeneratedBy;
> 
>    /**
>     * Gets the value of the entityOrActivityOrWasGeneratedBy property.
>     * 
>     * <p>
>     * This accessor method returns a reference to the live list,
>     * not a snapshot. Therefore any modification you make to the
>     * returned list will be present inside the JAXB object.
>     * This is why there is not a <CODE>set</CODE> method for the entityOrActivityOrWasGeneratedBy property.
>     * 
>     * <p>
>     * For example, to add a new item, do as follows:
>     * <pre>
>     *    getEntityOrActivityOrWasGeneratedBy().add(newItem);
>     * </pre>
>     * 
>     * 
>     * <p>
>     * Objects of the following type(s) are allowed in the list
>     * {@link JAXBElement }{@code <}{@link Association }{@code >}
>     * {@link JAXBElement }{@code <}{@link EmptyCollection }{@code >}
>     * {@link JAXBElement }{@code <}{@link Specialization }{@code >}
>     * {@link JAXBElement }{@code <}{@link Removal }{@code >}
>     * {@link JAXBElement }{@code <}{@link Dictionary }{@code >}
>     * {@link JAXBElement }{@code <}{@link Organization }{@code >}
>     * {@link JAXBElement }{@code <}{@link EmptyDictionary }{@code >}
>     * {@link JAXBElement }{@code <}{@link Plan }{@code >}
>     * {@link JAXBElement }{@code <}{@link Start }{@code >}
>     * {@link JAXBElement }{@code <}{@link Agent }{@code >}
>     * {@link JAXBElement }{@code <}{@link Collection }{@code >}
>     * {@link JAXBElement }{@code <}{@link Mention }{@code >}
>     * {@link JAXBElement }{@code <}{@link Generation }{@code >}
>     * {@link JAXBElement }{@code <}{@link SoftwareAgent }{@code >}
>     * {@link JAXBElement }{@code <}{@link Derivation }{@code >}
>     * {@link JAXBElement }{@code <}{@link KeyValuePair }{@code >}
>     * {@link JAXBElement }{@code <}{@link Object }{@code >}
>     * {@link JAXBElement }{@code <}{@link Communication }{@code >}
>     * {@link JAXBElement }{@code <}{@link Attribution }{@code >}
>     * {@link JAXBElement }{@code <}{@link Delegation }{@code >}
>     * {@link JAXBElement }{@code <}{@link Entity }{@code >}
>     * {@link JAXBElement }{@code <}{@link Influence }{@code >}
>     * {@link JAXBElement }{@code <}{@link Usage }{@code >}
>     * {@link JAXBElement }{@code <}{@link Alternate }{@code >}
>     * {@link JAXBElement }{@code <}{@link Membership }{@code >}
>     * {@link JAXBElement }{@code <}{@link Bundle }{@code >}
>     * {@link JAXBElement }{@code <}{@link End }{@code >}
>     * {@link JAXBElement }{@code <}{@link Insertion }{@code >}
>     * {@link JAXBElement }{@code <}{@link Activity }{@code >}
>     * {@link JAXBElement }{@code <}{@link Invalidation }{@code >}
>     * {@link JAXBElement }{@code <}{@link Person }{@code >}
>     * {@link JAXBElement }{@code <}{@link Revision }{@code >}
>     * {@link JAXBElement }{@code <}{@link Quotation }{@code >}
>     * {@link JAXBElement }{@code <}{@link PrimarySource }{@code >}
>     * {@link JAXBElement }{@code <}{@link DictionaryMembership }{@code >}
>     * 
>     * 
>     */
>    public List<JAXBElement<?>> getEntityOrActivityOrWasGeneratedBy() {
>        if (entityOrActivityOrWasGeneratedBy == null) {
>            entityOrActivityOrWasGeneratedBy = new ArrayList<JAXBElement<?>>();
>        }
>        return this.entityOrActivityOrWasGeneratedBy;
>    }
> 
>> 
>> My concern about choice in prov  attributes is that they lead, by default, to non natural object mapping with jaxb.  I believe jaxb matters because jaxb is a community standard reaching well beyond the java community.
> 
> I agree.  Would having a section in the FAQ which analyzes the problem in the context of a specific ORM technology and provides possible solutions (hints and/or alternate schemas) for that technology be satisfiable?
> 
> Also, looking at the JAXB generated class I think the manner in which the schema defines and uses prov:ref will result in a mapping that is not natural.
> 
> The following components from the schema
> 
>  <xs:complexType name="Generation">
>    <xs:sequence>
>      <xs:element name="entity" type="prov:IDRef"/>
>      <xs:element name="activity" type="prov:IDRef" minOccurs="0"/>
>      <xs:element name="time" type="xs:dateTime" minOccurs="0"/>
>      <xs:choice minOccurs="0" maxOccurs="unbounded">
>        <xs:element ref="prov:location"/>
>        <xs:element ref="prov:role"/>
>        <xs:element ref="prov:label"/>
>        <xs:element ref="prov:type"/>
>        <xs:any namespace="##other"/>
>      </xs:choice>
>    </xs:sequence>
>    <xs:attribute ref="prov:id"/>
>  </xs:complexType>
> 
>  <!-- note, this is not xs:IDREF -->
>  <xs:complexType name="IDRef">
>    <xs:attribute ref="prov:ref" use="required" />
>  </xs:complexType>
> 
> result in class members with type IDRef
> 
>    protected IDRef entity;
>    protected IDRef activity;
> 
> Whose class is defined like so:
> 
> @XmlAccessorType(XmlAccessType.FIELD)
> @XmlType(name = "IDRef")
> public class IDRef {
> 
>    @XmlAttribute(name = "ref", namespace = "http://www.w3.org/ns/prov#", required = true)
>    protected QName ref;
> 
>    /**
>     * Gets the value of the ref property.
>     * 
>     * @return
>     *     possible object is
>     *     {@link QName }
>     *     
>     */
>    public QName getRef() {
>        return ref;
>    }
> 
>    /**
>     * Sets the value of the ref property.
>     * 
>     * @param value
>     *     allowed object is
>     *     {@link QName }
>     *     
>     */
>    public void setRef(QName value) {
>        this.ref = value;
>    }
> 
> }
> 
> I think our modeling of prov:ref will likewise cause confusion among ORM generated classes.
> 
> --Stephan
> 
>> 
>> Now, I am not expert in jaxb. There may well be standard jaxb annotations that allow us To support a natural object mapping with an xsd choice. If so, we should go for xsd:choice.
>> 
>> Curt's suggestion of a plugin (-simple) is a good, as long as plugin is maintained, which with my jaxb experience, is not encouraging, especially.
>> 
>> 
>> In the absence of standard jaxb annotations that lead to natural jaxb mappings, my preference is to be conservative and go for ordered prov attributes.
>> 
>> 
>> Professor Luc Moreau
>> Electronics and Computer Science
>> University of Southampton 
>> Southampton SO17 1BJ
>> United Kingdom
>> 
>> On 6 Feb 2013, at 20:08, "Stephan Zednik" <zednis@rpi.edu> wrote:
>> 
>>> After having played around with JAB and gaining a better understanding of the problem I am more amenable to the idea of requiring element ordering for properties.
>>> 
>>> I am still not sold on the idea of element ordering in documentElements and without that the generated class methods for Bundle will be a 'bag of hurt'.
>>> 
>>> An alternate idea is a to have a section in the FAQ dedicated to providing ORM implementation-specific tips on how to generate 'nice' mappings.
>>> 
>>> The plugin Curt has mentioned could be mentioned in a FAQ entry and we could provide an example of how to use external hints to JAXB.  The FAQ could also contain links to a modified schema that uses ordered elements and is only intended to be used as a source for ORM mappings, but not as a schema to validate against.
>>> 
>>> I think I like the second option best as it allows us to respond to ORM-mapping issues after the WG activity has completed and is a natural way to talk about implementation specific ORM issues.
>>> 
>>> --Stephan
>>> 
>>> On Feb 5, 2013, at 11:56 AM, Curt Tilmes <Curt.Tilmes@nasa.gov> wrote:
>>> 
>>>> Luc,
>>>> 
>>>> I haven't tested this yet, but is it possible that the jaxb
>>>> "Simplify" plugin could address this problem with jaxb?
>>>> 
>>>> http://confluence.highsource.org/display/J2B/Simplify+Plugin
>>>> 
>>>> It seems (again, untested), that you could use it and specify
>>>> some application hints for jaxb ("simplify:as-element-property")
>>>> for the attributes that would instruct jaxb to model
>>>> each attribute family (type, location, label, etc.) with
>>>> its own list rather than bundling them together as it
>>>> does by default with choices.
>>>> 
>>>> Curt
>>>> 
>>>> On 02/05/2013 01:37 AM, Luc Moreau wrote:
>>>>> Hi Curt,
>>>>> 
>>>>> Does the schema  now impose an order on prov "attributes"?
>>>>> 
>>>>> Without order, I have failed to define an object mapping (with jaxb)
>>>> that is useful from an OO perspective. Likewise, i have not managed to
>>>> define a meaningful ORM mapping. Now, this is my experience with these
>>>> tools, maybe somebody has succeeded.
>>>>> 
>>>>> In summary, The problem I encountered is as follows. If there is a
>>>> choice (instead of sequence) between say, prov:type, prov:location,
>>>> prov:label, all these elements are mapped to a single java method or a
>>>> single sql column. This results in non natural code or SQL queries.
>>>>> 
>>>>> Because of this, my preference is to keep these in a sequence. It does
>>>> not at all reduce expressivity, I think.
>>>>> 
>>>>> 
>>>>> Professor Luc Moreau
>>>>> Electronics and Computer Science
>>>>> University of Southampton
>>>>> Southampton SO17 1BJ
>>>>> United Kingdom
>>>>> 
>>>>> On 5 Feb 2013, at 01:17, "Curt Tilmes" <Curt.Tilmes@nasa.gov> wrote:
>>>>> 
>>>>>> Last week, we also briefly mentioned the PROV-XML element
>>>>>> ordering issue, described here:
>>>>>> 
>>>>>> https://www.w3.org/2011/prov/track/issues/572
>>>>>> 
>>>>>> Are there strong opinions about changing anything (either
>>>>>> arguments, or attributes or anything else from the way it
>>>>>> is now?
>>>>>> 
>>>>>> Tracker, this is ISSUE-572.
>>>>>> 
>>>>>> Curt
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Curt Tilmes, Ph.D.
>>>> U.S. Global Change Research Program
>>>> 1717 Pennsylvania Avenue NW, Suite 250
>>>> Washington, D.C. 20006, USA
>>>> 
>>>> +1 202-419-3479 (office)
>>>> +1 443-987-6228 (cell)
>>>> globalchange.gov
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
>

Received on Thursday, 7 February 2013 06:15:09 UTC