- From: Stephan Zednik <zednis@rpi.edu>
- Date: Thu, 7 Feb 2013 09:57:50 -0700
- To: Curt Tilmes <Curt.Tilmes@nasa.gov>
- Cc: Luc Moreau <l.moreau@ecs.soton.ac.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
- Message-Id: <6D5AD364-A1B4-43B8-9074-80058FD032FA@rpi.edu>
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
Received on Thursday, 7 February 2013 16:58:26 UTC