OASIS ebXML Messaging Services TC

Pim,
 
I agree - since refactoring the type definitions to permit reuse is merely a XSD related syntax device - and does not change the actual schema structure and content model - it does qualify as an errata and oversight that was not caught in the original.


Thanks, DW
 
 

-------- Original Message --------
Subject: [ebxml-msg] Refactoring the ebMS schema
From: "Pim van der Eijk" <pvde@sonnenglanz.net>
Date: Tue, February 09, 2010 7:27 pm
To: <ebxml-msg@lists.oasis-open.org>


Hello,

Following up on the last bullet from my message below:

The ebint:RoutingInput schema attempts to reuse as much as
possible the ebMS 3.0 Core schema for elements in
UserMessage. Unfortunately, there is only an eb3:Messaging
element that can be reused when importing the ebMS 3.0 Core
schema into other schemas. All other elements are local to
that element's type, and the same is true for its
subelements and their types. As a result, the ebint schema
in
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/docum
ent.php?document_id=33933 has to define not only a new
ebint:UserMessage, but also ebint:MessageInfo,
ebint:PartyInfo, ebint:CollaborationInfo and
ebint:PayloadInfo. Is this acceptable or undesirable?

If the latter, here is an approach: it is possible to
refactor the ebMS 3.0 Core schema to have reusable element
definitions for MessageInfo, PartyInfo, CollaborationInfo
and PayloadInfo. See attached:
"ebms-header-3_0-200704_refactored.xsd"
This allows the ebint schema to reuse the elements from this
schema. See attached:
"ebms-multihop-1_0-200902_refactored.xsd"
An example that is valid against this ebint schema is
attached: "example_ebint.xml"
The difference to the examples posted in
http://lists.oasis-open.org/archives/ebxml-msg/201001/msg000
22.html is that there the subelements are from the ebint
schema.

The ebint:UserMessage has an optional MessageInfo, so that
element (and its type) should stay in the ebint schema as
the ebMS 3.0 Core UserMessage has a required MessageInfo.

The refactored ebMS 3.0 Core schema validates the exact same
messages as the ebMS 3.0 Core Spec. The attached regular
ebMS 3.0 core "example.xml" is valid with both the 3.0 Core
XSD and the refactored schema. Since the exact same
instances are valid or invalid in both schemas, I think the
refactored XSD for the Core schema could qualify as an
erratum only.

What do people think?

Pim


-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: 31 January 2010 21:55
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Remaining work on Part 2


Hello,

The lists of things to do to finish part 2 includes at
least:
- Some discussion on Pulling. In Core spec, you could pull
submitted user messages (or get an EmptyMPCError). In Part
2, you can Pull anything that has an ebint:RoutingInput to
it. And some of those things were not "submitted" (to an
MSH by an application) but received (from another MSH) for
forwarding.
- Review all options for Pull requests (from edge
intermediary, end-to-end pulling, something in-between):
when do they need a reference parameter, when do they need a
nextmsh @role, verify that we can configure all options
using the current Pmodes.
- The ebint:RoutingInput schema could reuse more from the
Core Spec if we had global elements other than just
eb3:Messaging. Is that an option?
- Add some text on ConversationId in RoutingInput (Not set
via Pmode, do we leave this to implementations or recommend
some approaches ?)
- General editorial work (language, references, formatting,
style etc.).
- Thorough review ..

Other than this we are almost there ..

Pim



-----Original Message-----
From: pvde@sonnenglanz.net [mailto:pvde@sonnenglanz.net]
Sent: 31 January 2010 21:35
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Groups - ebMS v3.0: Part 2, Advanced
Features (v51) (ebMS3-part2-V51.odt) uploaded

Changes in v50 and v51

Updated based on TC meeting of January 27th. (Line numbers
as in "Show
Changes" in OpenOffice).

Section 1:
Changed wording that might suggest this spec defines support
for WS-SecureConversation fully.

Section 1.3:
There is a more recented WSRSP draft.

Section 2.1, 2.2:
Minor textual edits.

Section 2.4.3:
Improved WSIRSP reference.

Section 2.4.5:
As discussed, the "next" role value is on wsa:To and
ebint:RoutingInput.
Not on wsa:Action. PMode parameter determines presence on
eb3:Messaging.

Section 2.5.4
Formatting.

Section 2.5.5:
@role attribute

Section 2.5.6.
Expiration in WS-Security added to discussion of
WS-Reliability

Section 2.6.1
The EPR PMode is now embedded in a new Adressing group.

Section 2.6.3.1
@role and formating.

Section 2.6.3.2
Changing recommended to default.

Section 2.7
New Addressing group.
Lots of textual changes due to this.

Section 2.8.2
Indication that this document is not a complete
WS-SecureConversation profile.

Section 3.
Lots of (mainly textual) improvements based on review.

Section 4.2
New Addressing level.

Section 4.4
Introducing errorhandling.Report.ReceiverErrors.ReplyPattern

Section 4.6.2
Disclaimer on WS-SecureConversation.

Appendix D, E, F:
Updated examples for @role attribute and wsa headers.
Also WS-Security improvements (signed timestamps in all
examples).






-- Mr. Pim van der Eijk

The document revision named ebMS v3.0: Part 2, Advanced
Features (v51)
(ebMS3-part2-V51.odt) has been submitted by Mr. Pim van der
Eijk to the OASIS ebXML Messaging Services TC document
repository. This document is revision #21 of
ebMS3-part2-V32-JD.odt.

Document Description:


View Document Details:
http://www.oasis-open.org/committees/document.php?document_i
d=36168

Download Document:
http://www.oasis-open.org/committees/download.php/36168/ebMS
3-part2-V51.odt

Revision:
This document is revision #21 of ebMS3-part2-V32-JD.odt.
The document details page referenced above will show the
complete revision history.


PLEASE NOTE: If the above links do not work for you, your
email application may be breaking the link into two pieces.
You may be able to copy and paste the entire link address
into the address field of your web browser.

-OASIS Open Administration


------------------------------------------------------------
---------
To unsubscribe from this mail list, you must leave the OASIS
TC that generates this mail. Follow this link to all your
TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_work
groups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php