Dear GRAAP members, one of the last open issues for the next release of our spec was the semantics of compositors and the use of templates. There were some concerns about using compositors on a template as well as offer/agreement level, potentially introducing semantic ambiguity as to who must or can exercise options. After some discussion since the last call, Toshi, karl and I propose the following, to be discussed in today's call: 1. Compositors have agreement offer-level semantics only. They are not to be interpreted as choices of the initiator. 2. To express more flexibility, we propose to extend the CreationConstraints as follows: Add an attribute "mode" to Location that can be "insert" or "replace". If the value is set to replace, have another attribute "before" with values of positive integers and "end". With those instruments in addition to complex types in creation contraints we can express, for example, the following: ... <wsag:ServiceDescriptionTerm> <ns1:docroot> <ns1:fieldA>myfixedvalue</ns1:fieldB> <ns1:fieldB>default value</ns1:fieldB> </ns1:docroot> </wsag:ServiceDescriptionTerm> ... <CreationConstraints> <Item name="i1"> <Location mode="replace">//ns1:fieldB<Location> <xsd:restriction base="xsd:string"> <xsd:enumeration value="foo"/> <xsd:enumeration value="bar"/> </xsd:restriction> </Item> <Item name="i2"> <Location mode="insert" before="end">//ns1:docroot<Location> <xsd:sequence maxOccurs="128"> <xsd:element ref="ns1:fieldC"/> // You could inline a more complex element here. <xsd:choice minOccurs="0"> // To any fieldB element, we can add more arbitrary input, e.g., file names etc. <xs:element ref=wsgram:FileStageIn minOccurs=0 maxOccurs=unbounded/> </xsd:choice> </xsd:sequence> </Item> </CreationConstraints> Using the added expressivness of the Location element, we can deal with zero or more cardinalities. I propose to use schema for associating the occurrance of one element (fieldC) with another (fieldC). You cannot express this in either the Infoset notation nor the compositors. This way, we achieve a pretty powerful composition semantics, do not replicate expressivness covered by schema and don't need template-level compositors. Talk to you at 11 EST, Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig@us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/