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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

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


Subject: RE: [ebxml-iic] New DP Template


Title: RE: [ebxml-iic] New DP Template

Pete:

-----Original Message-----
From: Pete Wenzel [mailto:pete@seebeyond.com]
Sent: Tuesday, May 03, 2005 8:38 AM
To: ebxml-iic@lists.oasis-open.org
Subject: [ebxml-iic] New DP Template

Jacques asks:
> Can you quickly review the two docs posted today on our site:
> (a) an update of the general Deployment Profile Template document structure
> (meta-data), as proposed for replacement of the old one.
> (b) a draft of what the ebMS 2.0 Template conforming to this meta-data would
> look like.
> And tell me what you'd vote on approving the new template structure?
> (I'll put it to vote later this week...)

I looked through the Template, and the meta-Template, and believe they
capture everything we need.  I would be in favor of proceeding in this
direction.

I am wondering about the "Test References" field, however.  It seems
to me that in ECOM's guide, this is intended and used as a further
narrowing of the "Profiling" field: similar in nature, but more
specific, because it is only applicable within a certain (test)
context.  Could this be better handled through a separate instance of
the profile, which is used to describe the profiling requirements for
a specific test environment?

<JD> Given that a deployment guide actually is the definition of a profile by a user community, it is useful that each requirement actually be linked with the test requirement or test case that is associated with it (if exists at that time), but via a test *reference*. The ECOM deployment guide probably goes too far: should not do more than just referring to test reqs or test cases that are defined somewhere else (instead of sometimes describing the test req).


For example, we would have ECOM Deployment Profile for ebMS, in which
"Profiling" field contains allowed values/ranges/etc. narrowed from
the base specification.  Then we would have a separate ECOM ITG Test
Profile for ebMS, which would contain the more-constrained values in
its "Profiling" field, to be used only when implementing the ITG Test
Suite, instead of the original values.  The second document does not
have as wide a scope of applicability as the first, so maybe we should
not encourage them to be mixed into one document.

<JD> Tests requirements and test suites associated with a Profile should be defined somewhere else indeed. Maybe we just need to make it clear that the Profile doc should contain no more than references to these?

Jacques



--Pete
Pete Wenzel <pete@seebeyond.com>
Senior Architect, SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)

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



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