RE: [ebxml-msg] Issue 74: foreign namespace attributes

[David Fischer <david@drummondgroup.com>]

+1

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Wednesday, February 13, 2002 6:55 PM
To: Arvola Chan
Cc: Doug Bunting; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Issue 74: foreign namespace attributes


+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 <dougb62@yahoo.com <mailto:dougb62@yahoo.com>>
>     To: ebxml-msg@lists.oasis-open.org
>     <mailto:ebxml-msg@lists.oasis-open.org>
>     <ebxml-msg@lists.oasis-open.org <mailto:ebxml-msg@lists.oasis-open.org>>
>     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> 
> 



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>