- From: Curt Tilmes <Curt.Tilmes@nasa.gov>
- Date: Thu, 7 Feb 2013 06:12:07 -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: <51138C07.6050805@nasa.gov>
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
Received on Thursday, 7 February 2013 11:12:34 UTC