[jsdl-wg] GGF 13 notes and further discussion

[Ali Anjomshoaa]

You have a good point here Chris. I'm glad you're making your point and
staying consistent with the views you expressed much earlier for JSDL :)

We agreed at the telecon on Tuesday that we're leaving this discussion for
post-v1.0, even post bug-fixes if we can.

Cheers,

Ali


On Wed, 30 Mar 2005, Christopher Smith wrote:

> Given that JSDL is defining an ontology of terms so that we can all
> understand what is meant by "command line" or "file transfer", isn't the
> determination of mandatory or optional a bit out of scope? I can easily see
> a system based on negotiation where the two parties agree on which terms are
> consumable by the end system, so you can get this behaviour that way.
> 
> I guess I just worry that the user of JSDL's expectations for a particular
> job submission behaviour are met. Wouldn't it be nice to know if a
> particular attribute is rejected or not? This seems to me to be part of the
> submission protocol layer.
> 
> -- Chris
> 
> 
> On 29/3/05 01:30, "Ali Anjomshoaa" <ali at epcc.ed.ac.uk> wrote:
> 
> > 
> > Hi Karl, Donal,
> > 
> > I think that the 'optional' vs. 'mandatory' attribute mark-up could work
> > for JSDL. However, we decided a long time ago that all specified
> > attributes in a JSDL doc MUST be satisfied, i.e. that there are NO
> > attributes that a system MAY consider optional in a job description.
> > 
> > I think we should perhaps reconsider this position. However, I also think
> > that this is something that we can leave for a post-v1.0 version of the
> > spec. It doesn't strike me as something that will break version 1.0
> > backward compatibility if introduced at a later stage.
> > 
> > So, I would vote to postpone this issue until after v1.0 has been released
> > and any bugs on that version are fixed.
> > 
> > Any thoughts on this?
> > 
> > Cheers and take care,
> > 
> > Ali
> > 
> > 
> > 
> > On Tue, 29 Mar 2005, Karl Czajkowski wrote:
> > 
> >> On Mar 29, Donal K. Fellows loaded a tape reading:
> >>> Karl Czajkowski wrote:
> >>>> Being able to mark some elements as mandatory and others as optional
> >>>> means that a consumer, for whatever reason, can filter out optional
> >>>> pieces and consider the remaining document as "equivalent" for the
> >>>> needs of the producer.  This allows the consumer to eliminate
> >>>> extensions that it does not understand as well as parts it understands
> >>>> but which conflict with its own policies.
> >>> 
> >>> The problem is that there's no way for us to force such attributes on
> >>> extension elements (I think) and we don't need it for any non-ext
> >>> elements in JSDL since the spec has everything as "must understand"
> >>> (though a consumer could reject the doc if it doesn't "support" the term
> >>> in question).
> >>> 
> >> 
> >> We could do it via a wrapper... I am proposing this sort of mechanism
> >> in WS-Agreement as well:
> >> 
> >>   1. treat elements in xsd:any extensibility slots as mandatory/critical
> >> 
> >>   2. except, if wrapped in jsdl:noncriticalExtension which is an
> >>      element w/ exactly one xsd:any##other in its body
> >> 
> >> karl
> >> 
> >> -- 
> >> Karl Czajkowski
> >> karlcz at univa.com
> >> 
> >> 
> > 
> > --
> > 
> >         ---------------------------------------------------- |epcc| -
> >         Ali Anjomshoaa
> >         EPCC, University of Edinburgh
> >         James Clerk Maxwell Building
> >         Mayfield Road                   E-mail: ali at epcc.ed.ac.uk
> >         Edinburgh EH9 3JZ               Phone:  + 44 (0) 131 651 3388
> >         United Kingdom                  Fax:    + 44 (0) 131 650 6555
> >         -------------------------------------------------------------
> > 
> 
> 

--

        ---------------------------------------------------- |epcc| -
        Ali Anjomshoaa
        EPCC, University of Edinburgh
        James Clerk Maxwell Building
        Mayfield Road                   E-mail: ali at epcc.ed.ac.uk
        Edinburgh EH9 3JZ               Phone:  + 44 (0) 131 651 3388
        United Kingdom                  Fax:    + 44 (0) 131 650 6555
        -------------------------------------------------------------