issues

[John Fuller <jfuller@wernervas.com>]

GetProperties
		Methods like GetInstanceProperties and GetFactoryProperties
		would allow us to retrieve the particular properties we may be
		interested in and allow us to dispatch off the method.

		If the properties were really intended to be implemented as a set  
instead,
		WS Resource Properties provides ways to do this:
		for a single property, a list of qnames representing the properties,
		or a properties conforming to a query.
		While this would be nice to support, it would take some time to  
implement.
  		An advantage of only returning some properties is if context data or  
history
		are huge and not necessary for a client who just wants the current  
state.

		Since context data can be arbitrarily complex, implementers may  
struggle
		with storage, retrieval, and management using a generic engine.
		Client implementers have sort of balked when introduced to this kind  
of type.

schema changes
		Eventually we should probably move to versioned namespace URLs.
		We can send our documents/locations to Webmaster@oasis-open.org
		so OASIS can serve them up to tools.
		ex:
			http://docs.oasis-open.org/asap/2004/04/asap-02/asap.xsd			http:// 
docs.oasis-open.org/asap/2004/04/asap-02/asap.wsdl

filter
		The operation to list instances allows for a filter which could use  
further
		specification.  Perhaps an XPath expression would be a good filter,
		but there are likely to be implementation issues with  
storage/retrieval.

context
		I know there was discussion that the execution context passed in the
		creation operation should mostly contain identifiers for a "claim  
check"
		pattern, rather than large data.
		WS-CAF has a context that goes in the headers, for transactions,  
security, etc,
		and the idea of context management services.
		Thoughts on integrating the two ideas?

states
		Should we go to a pattern representation for states?
		Stick with strings or go to URNs?