- From: Stephan Zednik <zednis@rpi.edu>
- Date: Thu, 7 Feb 2013 02:40:48 -0700
- To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Cc: Curt Tilmes <Curt.Tilmes@nasa.gov>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
- Message-Id: <2B9ABF2D-FA0F-4942-A233-32ACAE5BEF67@rpi.edu>
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 >
Received on Thursday, 7 February 2013 09:41:40 UTC