[dfdl-wg] Annotation complexity

[Myers, James D]

> 
> 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 agree, I think - if anotations are only on simple types. That would
eliminate the element hierarchy, though - does it eliminate the type
hierarchy - simple element in base type has an annotation that gets
inherited by the same simple element in a derived type. I think this
would be unambiguous, but perhaps hard to find (surprise the global dfdl
default for endianess doesn't apply because some subtype three levels
back had an annotation)

> 
> 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.

Except through type derivation...?

> 
> 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.

Definitions on sources: I know we've talked about this (!!! - the whole
outside-in or inside out representations...), but I think the only
mechanism for this in the examples is to assign a source to an element
and annotate that element with, for example, endianness. For some types
of sources, e.g. other layers, that have an internal structure, any
annotation of the source itself would essentially become an inheritable
annotation on the elements within it. So - we could try to define such a
mechanism to apply to sources, but I'm not sure it would be applicable
to all without recreating some of the inheritance issues.
> 
>   - 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.

Hmmm. Yes, as long as xpaths can only be defined from a single root,
i.e. not from within type definitions relative to the type (not talking
about layers here). Otherwise we don't get rid of inheritance/precedence
issues. At a minimum, this approach might help collect all of the
defaults together at the top level for readability, but it might
separate defaults from reusable types.

  Jim