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

[Jacques Durand <JDurand@us.fujitsu.com>]

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

Monica:

-----Original Message-----
From: Monica J Martin [mailto:Monica.Martin@Sun.COM]
Sent: Wednesday, May 04, 2005 2:45 PM
To: Jacques Durand
Cc: ebxml-iic@lists.oasis-open.org
Subject: Re: [ebxml-iic] Groups - Deployment Profile Template (Deployment_Profile_Template-5.doc) uploaded

Jacques,
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?

    * 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.

    * 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