+1
Arvola Chan wrote:
> Doug:
>
>
>
> I am in favor of option 7, i.e., wherever we introduce a wildcard
> element in the ebMS schema, we also have a corresponding wildcard
> attribute (under the same parent element). My rationale is to allow for
> the use of an xsi:schemaLocation attribute to indentify the schema for
> the foreign namespace used in the corresponding wildcard element.
>
>
>
> I agree that the namespace for the wildcard attributes should be
> "##other". I don't want to limit the wildcard attributes to only be
> drawn from the "http://www.w3.org/2001/XMLSchema-instance" namespace.
>
>
>
> Thanks,
>
> -Arvola
>
> -----Original Message-----
> From: Doug Bunting < <mailto:>>
> To:
> <mailto:>
> < <mailto:>>
> Date: Wednesday, February 13, 2002 3:55 PM
> Subject: Re: [ebxml-msg] Issue 74: foreign namespace attributes
>
> All,
>
> We seem to have gotten fairly far afield from the original issue
> number 74: A recommendation describing how our extension mechanisms
> should be used and pointing implementers to another option (defining
> their own SOAP extension elements). I specifically recommended that
> the first additional paragraph not be included if we went back to
> allowing foreign attributes in the schema. Irrespective of that
> decision (which hasn't been made yet), the non-normative Note I
> suggested adds value to the documentation.
>
> ------------------------------------------------------------------------
>
> The issue of foreign attributes is not captured in the current
> issues list because nobody has been able to cull the email archives
> for additional issues. I believe Arvola raised this issue most
> recently in an email entitled "Minor discrepancy between spec and
> schema". That thread ended with my comments [1] recommending
> wildcard attributes be allowed only on the Manifest and Reference
> elements, leaving the option for MessageHeader open. I was never
> recommending including this option in all top-level SOAP extension
> elements we're defining, which would be a major technical change to
> the protocol from 1.0 at a rather late stage. (In fact, it wouldn't
> help with extensions to the Reference element.) I was recommending
> a return to the foreign attributes that should have been supported
> in 1.0 but were (in the case of the MessageHeader element) slightly
> misplaced.
>
> I'd also point out our schema does not support wildcard elements
> everywhere, just in the Error, Reference and all top-level SOAP
> extension elements. This is a long list but not all of the elements
> we're defining. I could support following this same choice with
> respect to foreign attributes but would have trouble with extending
> all top-level SOAP extension elements without at least the Reference
> element.
>
> Foreign attribute options seem to be:
> 1) leave them out of the schema, as they are in the original 2.0 schema
> 2) return to the 1.0 state, including foreign attributes on the
> Manifest and MessageHeader elements
> 3) correct issue with 1.0 allowances and move foreign attributes
> from MessageHeader to Reference
> 4) include foreign attributes in all of Manifest, Reference and
> MessageHeader elements
> 5) include foreign attributes in all of the SOAP extension elements
> we define
> 6) do (5) and Reference element
> 7) do (6) and Error element, matching distribution of wildcard
> elements we presently support
>
> I proposed option (3) but think anything but (1) or (5) would be
> workable. (2) would be the least preferable of the remaining set.
> I don't believe we should be doing namespace="#any" or
> namespace="http://www.w3.org/2001/XMLSchema-instance" anywhere,
> namespace="#other" is the right choice as described in earlier
> emails on this thread [2].
>
> thanx,
> doug
>
> [1] http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00135.html
> [2] http://lists.oasis-open.org/archives/ebxml-msg/200202/msg00077.html
> <http://lists.oasis-open.org/archives/ebxml-msg/200202/msg00077.html>
>
