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 <>
To:
<>
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
