In GRAM, we have a notion of "substitution variables" which we have reduced in scope for WS-GRAM (web services GRAM in GT 4.0) to only be referenced in certain string values and only consisting of a fixed set of service-defined values. (In previous versions, we allowed the user to define their own substitution mappings.) I have been debating whether there is some reason JSDL needs to support this mechanism for use in GRAM. For values that are static, we can expose the service-defined values as resource properties and just require the client to have prefetched them and "written them in" where they would have used a variable reference. I do not see this as a problem since I never bought the idea that a job description must be "portable" in any sense. The biggest drawback to requiring clients to handle the write-in is when there are values that change on a per-job basis. Then, you need some chatty protocol to establish the job session, fetch its job-specific values, write them in, and then transmit the fully concrete job description. Does JSDL need a way to have free variable references in some of its string values, e.g. references that are understood in the context of a particular service and which are inherently not captured by the lexical scope of the JSDL instance document itself? If these variable names were URI/URNs, there would not be any semantic ambiguity... the consumer of the document would know whether they are capable of rewriting the references to make a meaningful JSDL document. karl On Apr 06, Ali Anjomshoaa loaded a tape reading:
Hi Hrabri,
we discussed this issue at some length at GGF13 and were unsure as to how to proceed. We would like to be able to reference labeled attributes, but, I think we're still discussing how to implement this issue in the xsd schema depending on current tooling!
I think, unfortunately, our choice of how we implement this in xsd will influence how we specify how to do this in the spec. Clearly this is not ideal and should be the other way round!
Watch the JSDL space and let us know how you do this in the end.
Cheers and take care,
Ali
-- Karl Czajkowski karlcz@univa.com