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