Re: PROV-XML element ordering

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 03:08:52 UTC