- From: Curt Tilmes <Curt.Tilmes@nasa.gov>
- Date: Thu, 7 Feb 2013 15:06:37 -0500
- To: Stephan Zednik <zednis@rpi.edu>
- CC: Luc Moreau <l.moreau@ecs.soton.ac.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
- Message-ID: <5114094D.4020601@nasa.gov>
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
> <mailto: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
>> <mailto: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
>>>> <mailto: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()
>>>>>
>>>>> 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 =*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 <http://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 Kingdomhttp://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, 7 February 2013 20:06:17 UTC