[dfdl-wg] Annotation complexity

[Martin Westhead]

Myers, James D wrote:
> I guess I'm not sure how restricting annotations to elements solves
> things.

Sorry, I am finding it more difficult to be precise than I thought with 
this. What I mean here is _leaf_ elements/attributes - which I think can 
be defined as elements with simple type descriptions. I think if you 
stick to these its unambiguous...no?

I think Mike has examples of annotations that he would like higher in 
the tree but with this extreme position there would be no inheritance.

Two other thoughts occur:
  - I think definitions applied to a data source are orthogonal to this 
scoping issue. We still need to understand precedence but that seems 
relatively easy to resolve.

  - Another approach would be to allow annotation locations to be 
specified using XPath. Since XPath can specify both specific locations 
and large groups of locations this could be quite powerful.


> I think I can recreate the problems in Martin's examples without
> putting annotations on types:
> 
> The issue of it being hard to understand that triple overrides the
> dfdlfromstrings param would seem to be the same whether the triple type
> has an annotation or if some subelements within it get annotations
> (either first second and third, or consider a triple type that specifies
> an annotated element containing those three). In all these cases, it is
> clear that you have to walk down the logical hierarchy which is broken
> into parts in the dfdl/xsd file and keep a stack of contexts if we allow
> any default/scoped annotations.
> 
> If annotations are allowed on both types and elements, what I find even
> more difficult are situations where the triple type has one default, and
> the element in "data" with that type has an annotation specifying the
> opposite param value. Do we consider the element to be above the type in
> the scope hierarchy? 
> 
> For more fun, what if triple is derived some other type where the
> annotation is defined. Would an annotation on the "data" element be
> inherited by the sub-element of type triple, or would the inheritance
> from the triple base type win (i.e. neither the element of the type
> triple or the triple type itself are directly annotated). (Or consider
> an annotation on the "first" element defined in the base type for triple
> rather than on the base type directly - does the element annotation
> inherited from the type hierarchy trump the one from the element
> hierarchy?)
> 
> An attempt at a picture where only elements have annotations:
> 
> Element A : param=littleendian		
>   SubElement B: type ST
> 						Type T:
> 						  SubElement C: param:
> bigendian
> 
> 						Type ST: subtype of T
> 
> What is the param value of element C at A/B/C?
> 
> 
> I guess I see a need to keep some hierarchically scoped defaults (a file
> that has some ascii info and then a base64 encoded section of
> littleendian stuff), but xsd makes it hard to define a single hierarchy.
> Perhaps some rule of precedence - resolve annotations from type to
> subtype first, then push those onto the stack of element scopes - would
> make things unambiguous, if not user friendly.
> 
>   Jim
> 
> 
>>-----Original Message-----
>>From: owner-dfdl-wg at ggf.org [mailto:owner-dfdl-wg at ggf.org] On 
>>Behalf Of Martin Westhead
>>Sent: Friday, November 19, 2004 1:38 PM
>>To: Martin Westhead
>>Cc: dfdl-wg at gridforum.org
>>Subject: Re: [dfdl-wg] Annotation complexity
>>
>>
>>Sorry the elements in the triple were all supposed to be of a simple 
>>type e.g.:
>>
>>    <xs:complexType name="triple">
>>      <xs:annotation>
>>        <xs:appinfo>
>>          <dfdlFromBinary/>
>>        </xs:appinfo>
>>      </xs:annotation>
>>      <xs:sequence>
>>        <xs:element name="first" type="xs:int"/>
>>        <xs:element name="second" type="xs:int"/>
>>        <xs:element name="third" type="xs:int"/>
>>      </xs:sequence>
>>    </xs:complexType>
>>
>>
>>    <xs:complexType name="data">
>>      <xs:annotation>
>>        <xs:appinfo>
>>          <dfdlFromStrings/>
>>        </xs:appinfo>
>>      </xs:annotation>
>>      <xs:sequence>
>>        <xs:element name="triple"/>
>>      </xs:sequence>
>>    </xs:complexType>
>>
>>Martin Westhead wrote:
>>
>>>Hi,
>>>
>>>I think I understand Suman's issue with annotations on the Schema 
>>>tree.
>>>(Please Suman tell me if I am right here).  The problem is, that 
>>>lexically there are many trees in an XSD. Whilst in 
>>
>>practice these can 
>>
>>>clearly be considered as a single tree (including, I think, 
>>
>>even the 
>>
>>>simple type hierarchies) by placing all the type 
>>
>>definitions inline, 
>>
>>>this is not the way they appear to the user. So for example 
>>
>>if I have a 
>>
>>>file with conflicting annotations looking like:
>>>
>>>  <xs:complexType name="triple">
>>>    <xs:annotation>
>>>      <xs:appinfo>
>>>        <dfdlFromBinary/>
>>>      </xs:appinfo>
>>>    </xs:annotation>
>>>    <xs:sequence>
>>>      <xs:element name="first" type="xs:int"/>
>>>      <xs:element name="second"/>
>>>      <xs:element name="third"/>
>>>    </xs:sequence>
>>>  </xs:complexType>
>>>
>>>
>>>  <xs:complexType name="data">
>>>    <xs:annotation>
>>>      <xs:appinfo>
>>>        <dfdlFromStrings/>
>>>      </xs:appinfo>
>>>    </xs:annotation>
>>>    <xs:sequence>
>>>      <xs:element name="triple"/>
>>>    </xs:sequence>
>>>  </xs:complexType>
>>>
>>>So what I imagined is that we would assume that the "triple" type is
>>>considered _inside_ the scope of the "data" type and so the 
>>>"dfdlFromBinary" tag wins.
>>>
>>>On the other hand the user sees two trees of equal depth with
>>>conflicting annotations. The examples can obviously get much more 
>>>intricate.
>>>
>>>The issue is really that the scope of the annotations is 
>>
>>not lexically
>>
>>>defined.  At some level this is just like having globally included 
>>>variables in a programming language. On the other hand we 
>>
>>have arbitrary 
>>
>>>levels of these.
>>>
>>>Suman is this the problem?
>>>
>>>If this is the problem, and we agree that it is too confusing to the
>>>user (my opinion is still out on this). Then I see that the 
>>
>>conclusion 
>>
>>>is to adopt an approach similar to IBM's that annotations 
>>
>>can appear 
>>
>>>only on <element> and <attribute> tags. Even the top level 
>>
>>of the file 
>>
>>>is confusing since there may be many files involved. I 
>>
>>guess we can also 
>>
>>>have runtime defaults and default settings set in the 
>>
>>standard. I don't 
>>
>>>like this conclusion incidentally, can someone convince me 
>>
>>it is the 
>>
>>>wrong one?
>>>
>>>Martin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
> 
>