- 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