RE: [dfdl-wg] Annotation complexity
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
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.
We used to have a similar concept in the IBM broker message model, we called it 'element qualifier'. A top level global element could carry a reference (XPATH) to an element it ultimately contained, for the purposes of overriding certain properties, including default value. We found that: a) Their use made the model much harder to understand b) The code we had to write was considerably more complex c) No customer ever admitted to using the capability We withdrew the facility with no deprecation warning in V5 (June 2003) and so far nobody has shouted. Was this the kind of thing you are proposing? Regards, Steve Steve Hanson WebSphere Business Integration Brokers, IBM Hursley, England Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 "Myers, James D" <jim.myers@pnl.go v> To Sent by: dfdl-wg@gridforum.org owner-dfdl-wg@ggf cc .org Subject RE: [dfdl-wg] Annotation complexity 19/11/2004 21:03
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
participants (2)
-
Myers, James D -
Steve Hanson