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

Re: PROV-XML element ordering

From: Stephan Zednik <zednis@rpi.edu>
Date: Thu, 21 Feb 2013 08:30:43 -0700
Cc: Luc Moreau <l.moreau@ecs.soton.ac.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Message-Id: <36BE802C-2B69-459C-BE05-0690303077DD@rpi.edu>
To: Curt Tilmes <Curt.Tilmes@nasa.gov>
Is this issue (http://www.w3.org/2011/prov/track/issues/572) ready to be closed?

--Stephan

On Feb 7, 2013, at 1:30 PM, Stephan Zednik <zednis@rpi.edu> wrote:

> I have committed change to prov-core.xsd to use ordered elements for prov attributes.
> 
> https://dvcs.w3.org/hg/prov/rev/3f1e31b0df28
> 
> I have also updated a few prov-xml test files in eg-40 to conform with the new required ordering of elements
> 
> https://dvcs.w3.org/hg/prov/rev/f95aa1566db7
> 
> --Stephan
> 
> On Feb 7, 2013, at 1:10 PM, Stephan Zednik <zednis@rpi.edu> wrote:
> 
>> Sounds good.  I will commit the change.
>> 
>> --Stephan
>> 
>> On Feb 7, 2013, at 1:06 PM, Curt Tilmes <Curt.Tilmes@nasa.gov> wrote:
>> 
>>> I was going to suggest the order from PROV-DM section 5.7.2 and table 8,
>>> which appears to be alphabetical...
>>> 
>>> Curt
>>> 
>>> On 02/07/2013 01:39 PM, Stephan Zednik wrote:
>>>> How about alphabetical?
>>>> 
>>>> --Stephan
>>>> 
>>>> On Feb 7, 2013, at 9:57 AM, Stephan Zednik <zednis@rpi.edu> wrote:
>>>> 
>>>>> Now I think it is time to determine what ordering we want to have.  Should we use alphabetic ordering?  order by expectations of usage?  I don't have a preference except that we are consistent.
>>>>> 
>>>>> --Stephan
>>>>> 
>>>>> 
>>>>> On Feb 7, 2013, at 4:12 AM, Curt Tilmes <Curt.Tilmes@nasa.gov> wrote:
>>>>> 
>>>>>> Agreed.  If we just explain clearly in the doc what the order is, anyone implementing can do it that way.
>>>>>> Most people will be using other tools to output the XML so the tool will hide the need for order from them
>>>>>> anyway.
>>>>>> 
>>>>>> Curt
>>>>>> 
>>>>>> On 2/7/13 4:40 AM, Stephan Zednik wrote:
>>>>>>> Ok. I am on-board with updating the schema to enforce element ordering on prov attributes.  I like the idea of using jax bindings + simplify plugin but I think that is too complex a solution.
>>>>>>> 
>>>>>>> --Stephan
>>>>>>> 
>>>>>>> On Feb 7, 2013, at 1:47 AM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote:
>>>>>>> 
>>>>>>>> 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()
>>>>>>>> 
>>>>>>>> public QName getId()
>>>>>>>> 
>>>>>>>> So, i think this works ok.
>>>>>>>> 
>>>>>>>> Luc
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> @XmlAccessorType(XmlAccessType.FIELD)
>>>>>>>>> @XmlType(name = "IDRef")
>>>>>>>>> public class IDRef {
>>>>>>>>> 
>>>>>>>>>     @XmlAttribute(name = "ref", namespace = MailScanner has detected a possible fraud attempt from "www.w3.org" claiming to be "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
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Curt Tilmes, Ph.D.
>>>>>> U.S. Global Change Research Program
>>>>>> 1717 Pennsylvania Avenue, NW, Suite 250
>>>>>> Washington, D.C. 20006, USA
>>>>> 
>>>> 
>>> 
>>> 
>>> -- 
>>> 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, 21 February 2013 15:31:13 UTC

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