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@ggf.org [mailto:owner-dfdl-wg@ggf.org] On Behalf Of Martin Westhead Sent: Friday, November 19, 2004 1:38 PM To: Martin Westhead Cc: dfdl-wg@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