{Disarmed} Re: PROV-XML element ordering

Hi Stephan,

Response interleaved.

On 07/02/2013 04:08, Stephan Zednik 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.
>    

I don't think the situation is the same.
A bundle/document has a containment relationship with respect to 
documentElements, whereas prov attributes, we want them
to appear as instance variables (with associated setters and getters).  
I am therefore fine, with all documentElments being
amalgamated in a single list.
> 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.
>       *
>    


We can easily improve on this, as I did in the provtoolbox:
See 
http://openprovenance.org/java/site/prov/apidocs/org/openprovenance/prov/xml/Document.html#getEntityOrActivityOrWasGeneratedBy()


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

alternate schemas is challenging, since you want any xml compatible with 
prov-xml to be readable by a jaxb-friendly schema.
> 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:
>
>    

Here, provtoolbox maps as follows:

http://openprovenance.org/java/site/prov/apidocs/org/openprovenance/prov/xml/Entity.html#getId()

publicQName  <http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/namespace/QName.html?is-external=true>  getId()


So, i think this works ok.

Luc


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

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

Received on Thursday, 7 February 2013 08:48:40 UTC