I would suggest a slight change in the use of attributes from foreign
namespaces when restoring this option to our schema. A little history...
The <anyAttribute/> element was part of the MessageHeader and Manifest
definition in the most recent schema that included it
(draft-msg-header-04.xsd). That was probably a mistake and it certainly led
to my confusion and incorrect suggestion to remove these options.
Why was I confused? Well, the only reason I'd heard for these
<anyAttribute/> options was in support of xsi:schemaLocation on the two
elements. That sounded as if it could have been actually the reason since
these elements "feel like" they were the only top-level SOAP extensions at
some point in time. (I'm not sure they ever were the only SOAP modules we
had.) It's a lousy reason because it uses a shotgun to swat a fly. Using
this reasoning as a basis, I proposed removing the two very inconsistent
inclusions of foreign attributes rather than adding seven more such options
(for the other SOAP modules). I also discarded specifically including
xsi:schemaLocation in all of our modules because it's much simpler to put
that information in the parent soap:Envelope, soap:Header and soap:Body
elements.
In thinking and talking more about these foreign attribute options, I've
come to think they're a very useful way to add attributes defined in other
schema to the generally useful Manifest and Reference elements. I was
recently reminded of the long discussion of using ds:Reference directly
rather than defining our own work-alike element. The problem arose because
ds:Reference doesn't support a simple extension mechanism through allowing
foreign attributes. The two most generally useful elements in our
specification are Manifest and Reference. I propose we include
<anyAttribute/> in their definitions. This would add the text Arvola
highlighted to those elements and modify the 2.0 schema.
So, why was <anyAttribute/> on MessageHeader a mistake? (It wasn't a
mistake to have it on the Manifest element.) It's not nearly as useful
beyond the boundaries we've defined but it was there in 1.0. I don't care
very much whether or not we restore this particular option.
thanx,
doug