Fw: [dfdl-wg] Annotation complexity

Tue Nov 23 03:29:59 CST 2004

One more thought in this area. XML Schema itself does not have the notion
of inheriting properties from a parent object. For example, if I have a
complex type that contains only integer elements, there is no facility to
factor out the xsd:type attribute from all the elements and instead set it
as an attribute of the complex type. Was this a deliberate decision? I'll
see if I can find out.

Regards, Steve

Steve Hanson
WebSphere Business Integration Brokers,
IBM Hursley, England
Internet: smh at uk.ibm.com
Phone (+44)/(0) 1962-815848
----- Forwarded by Steve Hanson/UK/IBM on 23/11/2004 09:27 -----

             Steve                                                         
             Hanson/UK/IBM                                                 
                                                                        To 
             22/11/2004 11:24          dfdl-wg at gridforum.org               
                                                                        cc 

                                                                   Subject 
                                       RE: [dfdl-wg] Annotation complexity 
                                       (Document link: Steve Hanson)       

> 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 at uk.ibm.com
Phone (+44)/(0) 1962-815848

             "Myers, James D"                                              
             <jim.myers at pnl.go                                             
             v>                                                         To 
             Sent by:                  dfdl-wg at gridforum.org               
             owner-dfdl-wg at 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