[jsdl-wg] RE: [drmaa-wg] making a custom file path for output

Karl Czajkowski karlcz at univa.com
Wed Apr 6 07:16:56 CDT 2005


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 at univa.com





More information about the jsdl-wg mailing list