MHonArc v2.5.2 -->
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
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC