OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ebxml-msg] Issue 74: foreign namespace attributes

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.
-----Original Message-----
From: Doug Bunting <dougb62@yahoo.com>
To: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
Date: Wednesday, February 13, 2002 3:55 PM
Subject: Re: [ebxml-msg] Issue 74: foreign namespace attributes


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].


[1] http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00135.html
[2] http://lists.oasis-open.org/archives/ebxml-msg/200202/msg00077.html

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC