All, as the last outstanding item before closing on the final V1 of WS-Agreement, we need to settle on the use of strings, QNames and NCNames for descriptive names and IDs that we use in the schema and spec. Right now, it is a merry mixture, following various trends in the past. We have a number of options to address the restrictions that should apply to unique identfiers and desriptive names: - Unique identifiers could be strings (no restriction), QNames (one can/must use namespaces to structure ids), or NCNames (no QName). There are pros and cons to all of them but the most likely candidates seem to be strings or QNames. I don't see implementation reasons for NCNames right now. - Descriptive names could be strings or we may force NCNames. I don't see the point of telling people how they would like to call their agreement etc. descriptively. If a users thinks a:b:c tells him or her what is meant who wants to object. So I strongly propose the first. Applying the above thoughts to the schema, we yield: - a schema where all ids are QNames and all descriptive names are strings: - a schema where all ids and names are strings: To decide what is an id and what is a descriptive name I strictly went by the name of the attribute, finishing with Id or not. This might not be correct. For example, ServiceName coul dreally be an ID. Then we should call it that way and make it whatever we decide. If we go with string ids, it doesn't matter. This point is to be concluded in tomorrow's phone call and then applied to the text of the spec in the following day or two. 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/