Re: PROV-ISSUE-572: What constraints should we have on ordering of elements within the main complexTypes? [XML Serialization]

Hi Curt,

I wondered what makes it easier to use in automated engines.

 My tendency would be toward A which is the most open of the approaches.

cheers
Paul


On Thu, Oct 11, 2012 at 2:49 PM, Provenance Working Group Issue
Tracker <sysbot+tracker@w3.org> wrote:
> PROV-ISSUE-572: What constraints should we have on ordering of elements within the main complexTypes? [XML Serialization]
>
> http://www.w3.org/2011/prov/track/issues/572
>
> Raised by: Curt Tilmes
> On product: XML Serialization
>
> (Caution, the word "attributes" is overloaded between PROV-N and
> XML -- consider context for the meaning of that word.)
>
> Within the PROV-N specification for most of our types, the syntax is
> something like this:
>
> something(id; a, b, c, attrs);
>
> where
>
> * a,b,c are either required or optional fields and
>
> * attrs are optional attributes to be specified as a set of
>   attribute-value pairs
>
>
> Thoat attributes can include specified prov:* fields like
> prov:location, prov:role, etc. or other fields in some other
> namespace.
>
>
> The current approach to developing the XML complexType for
> each of those is to:
>
> * make prov:id an attribute of the type
>
> * make each of the a,b,c, XML elements and to require they be
>   specified in the same order as the PROV-N
>
> * also make the attributes XML elements, require that they be
>   after the primary a,b,c fields, but they can be specified in
>   any order.
>
>
> The XML schema for the type becomes something like this:
>
>   <xs:complexType name="something">
>     <xs:sequence>
>       <xs:element name="a" type="..."/>
>       <xs:element name="b" type="..."/>
>       <xs:element name="c" type="..." minOccurs="0"/> (optional)
>       <xs:choice minOccurs="0" maxOccurs="unbounded">
>         <xs:element name="location"/>
>         <xs:element name="role"/>
>         <xs:element name="label"/>
>         <xs:element name="type"/>
>         <xs:any namespace="##other"/>
>       </xs:choice>
>     </xs:sequence>
>     <xs:attribute ref="prov:id"/>
>   </xs:complexType>
>
>
> So, for example:
>
> used(a1, e1, 2011-11-16T16:00:00, [ ex:parameter="p1" ])
>
> becomes
>
>   <prov:used>
>     <prov:activity prov:ref="a1"/>
>     <prov:entity prov:ref="e1"/>
>     <prov:time>2011-11-16T16:00:00</prov:time>
>     <ex:parameter>p1</ex:parameter>
>   </prov:used>
>
>
> There is some concern over the constraint on the ordering, either
> to make it more strict, or less strict.
>
>
> Here are a few options (there are others and hybrids):
>
> A: Leave it the way it is now.
>
>    This can allows mixing attributes so e.g. you can specify a
>    prov:type, then a prov:location, then another prov:type.
>
>    It also allows mixing prov: namespace attributes with
>    non-prov: namespace attributes in any order.
>
> B: Require all prov: namespace attributes to precede all
>    non-prov: namespace attributes, but still don't require a
>    specific prov:* attribute order.
>
> C: Require strict ordering of the prov: namespace attribute
>    fields in addition to strict ordering of the other elements.
>
>    So, e.g. if you including a prov:type and a prov:label field,
>    you must put the prov:label prior to the prov:type, and you
>    get a validation error if you specify them in the wrong order.
>
> D: Remove all ordering
>
>    You could, e.g. specify a prov:type prior to the activity or
>    entity elements.
>
>
>
>



-- 
--
Dr. Paul Groth (p.t.groth@vu.nl)
http://www.few.vu.nl/~pgroth/
Assistant Professor
- Knowledge Representation & Reasoning Group |
  Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam

Received on Friday, 12 October 2012 10:50:16 UTC