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: deployment template meta-data


Title: deployment template meta-data

All:

Following-up to the meeting yesterday:

Here is below what could be a generic structure for Deployment Guidelines (usable beyond ebXML).

This defines in fact some "profile meta-data", from which a Deployment Template specific to a particular specification can be created. From this template in turn a specific Deployment Guideline can be instantiated by a community.


Profile meta-data (generic doc structure + optionally XML markup)
        |
        |
        V
Deployment Template for ebMS (or other)
        |
        |
        V
Deployment Guideline ABC (for an ebMS user community, e.g. EAN-UCC)


For review,

jacques
 
----------------- meta-data, illustrated on a pseudo deployment template:

Deployment Guideline for Specification ABC
<this is the title of the Deployment Guideline document>

1. Usage Profile XYZ
<here, the name of a particular usage profile. A user community may want to create several of these in a Deployment Guideline for ABC. The Template simply would list all of the modules to be considered when profiling.>

1.1 Source Specification Modules
<Section that gives an overview of what functional modules in the source specification(s) are part of this profile. May outline choices made on major options, as well as binding decisions to other modules or other specifications. In the Template, all modules candidates for profiling would be listed here.>

1.2 Profile Requirements Details
<that would be a list of Profile Requirement Items, possibly organized by Spec Module>

1.2.1 Profile Requirement Item xyz123
< For each Profile Requirement Item, a table-like structure as below. In the Template, (a) and (b) are pre-filled. In a template instance (i.e. Guideline) the rest is filled as well, though optional if no profiling for this item. The "profiling" field must contain either some requirement, or one of the keywords - not applicable, no recommendation, pending.   >

(a)- Specification feature <description of the source specification item to be profiled>
(b)- Reference to specification <identifies the item in the source specification>
(c)- Profiling <how the item is profiled: option narrowing/selection, content formatting,
narrowing structure of XML complex element, content integrity constraint,...>
(d)- Alignment <dependency / alignment with other data, e.g. binding, either with other
spec item or external source>
(e)- Test References <references to related test requirements or test cases, that would verify
this profiling.>



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