Re: [ebxml-iic] Groups - Deployment Profile Template (Deployment_Profile_Template-5.doc) uploaded

[Monica J Martin <Monica.Martin@Sun.COM>]

> mm1: Thanks for pushing this forward. I have a few questions/comments 
> on this
> (thinking about how this could be a computable XML representation
> sometime in the future):
>
>     * For "alignment", more than one dependency or context may exist.
>       Therefore I would suggest we have an alignment type and allow for
>       multiple alignments to be specified.
>
> <JD> we may identify these in the comments that go with the meta-data, 
> so that users understand what they can put in "alignment". I am a bit 
> reluctant to introduce more formal classifications that users would 
> have to understand and abide by (alignment type). I would suggest that 
> we keep the template meta-data and its use "low key" for now: if it 
> becomes successfully used, then I think we could push it toward a more 
> formal representation. Also, after looking at how people use it, we 
> would have more ideas on how best to improve it?
>
mm2: Jacques, you had asked for some potential classification types. 
Some could be:

   1. protocol (binding)
   2. specification (in other than this one)
   3. reference (in this specification)
   4. content
   5. test context
   6. other (generic catch all other)

Note: One spec feature may be aligned with/dependent on many other 
references.

As we discussed, pend for later. Address now (if at all) in notes.

>     * Specification dependencies: Often times, you may see operational
>       semantics that supplement how a particular XML capability is
>       defined in the context of the schema and associated instance (For
>       example, in BPSS, our BT patterns and their use in the ebBP schema
>       and associated instance). Therefore a specificaiton reference may
>       have additional operational semantics that bound it. How can we
>       represent (or perhaps differentiate) dependencies as syntactic,
>       semantic, other and show their relationship?
>
> <JD> Same comment here: if we can point at various cases of 
> dependencies in the meta-data comments, I am all for it. But reluctant 
> to introduce a formal classification in the meata-data itself at this 
> time.
>
mm2: May be handled by alignment types specified above.  In addition, in 
looking back and this, and working through what could transpire, I think 
that a feature could have many spec references and align to many other 
references or dependencies (from multiple sources).  Therefore M-M. we 
need some way to leverage that as a later mechanism to, for example, 
quantify, "are we complete" from a test perspective.  Take a case from 
previous framework/profile development, we discussed that we couldn't 
fully test a feature because it required a perceived infinite number of 
test cases, requirements, and scenarios.  I think this association 
process would help us more so quantify what test bar is being achieved. 
Would metadata address:

   1. May be mandatory or optional.
   2. If optional but used, may have several options (choice must be made).
   3. If more than 1-more features must be tested together?
   4. etc.

Thanks.

>     * Notes: I would suggest we consider an approach that will lend
>       itself to computability later. Maybe this could be as simple as
>       putting a type on each note to differentiate. For example, a note
>       of description or annotation is different from one that restricts
>       when specific conditions exist (which raises the question if it is
>       a dependency or constraint). If we can limit how notes are used,
>       we may be able to more effectively use them later.
>
> <JD> same comments here too: maybe we can show what kinds of notes can 
> get in. But would not worry much about formal representation or 
> processability right now - in a future revision we could, after 
> getting enough input on how people use it.
>
> Cheers,
>
> Jacques
>