November 2004 - jsdl-wg - lists.ogf.org

RE: [jsdl-wg] application abstraction in JSDL (fwd)
by Lukichev, Alexander S 25 Nov '04

25 Nov '04

Donal, >Ali Anjomshoaa wrote: >> Fwding bounced mail... > >(Alexander, if you're going to be writing much about this, please join >the mailing list; it simplifies things greatly.) Sorry. I've subscribed now. > >"Lukichev, Alexander S" <alexander.s.lukichev(a)intel.com> >> Our team is currently develops an application that will use >> JSDL documents as input to invoke jobs in a distributed system. >> I'd like to comment if possible some aspects of the latest JSDL >> schema. > >When you say "latest schema", is this pre- or post- the recent >work done >at the face-to-face meeting? It is my impression that many of these >issues you raise were actually addressed there... :^) FYI, you should >refer to the document at >https://forge.gridforum.org/docman2/ViewCategory.php?group_id=1 >22&category_id=868 >which I believe is the most recent version of the spec. Well, I refer this one. >> Currently to describe the job to run you can specify: >> a) executable name >> b) arguments >> c) environment variables >> >> This could be not enough configurable because executables can >> reside at different places on the different systems, arguments >> can be passed in different ways to close applications on >> different systems, etc. Thus JSDL contains pretty enough >> information for locating the suitable server, the located server >> could fail to run the requested application because of lack of >> configuration information. > >Actually, there is no need to specify the executable name at all. An >alternative (that we would encourage people to use where possible) is >the "application name", and that provides the necessary abstraction. That's right. > We also support an extensible set of application "types" which will allow >for a much more sophisticated range of behaviour. The schema limits the possible values to several _types_ of applications like scripts, java classes, sql queries, etc. But how e.g. fortran compilation could be specified? Imagine that you don't know the details about the location of the fortran compiler and the compiler vendor. >> We can look at the UNICORE experience and try to configure >> the particular applications using the following entities: >> >> a) fields (i.e. partucular file names, argument values, >> e.g. "source=a.c", "size=1234") > >I see this as being a different interpretation on the Argument element >(which would require using a non-JSDL type for now, though this will >make for a powerful thing to do once we've got JSDL 1.0 out of >the door.) OK, so non-JSDL Argument could be a solution. > >> b) options (i.e. names for common modes of application >> work; though setting this mode could differ from >> system to system, e.g. "debug=on" results in passing >> "-g" to some compilers) >> c) contexts (modes for application invocations, e.g. >> "profiliration") > >Thess would be probably done with extension elements in the Application >element (unless of course they are more like Resources, when they'd go >somewhere else). Anyone else want to comment? > >> d) variations (variations of expected results, e.g. >> "overwrite" for file operations) > >I don't currently see how the current DataStaging element's >CreationFlag >and DeleteOnTermination sub-elements are insufficient. Please explain >further. Well, file operations can include "copy folder" or "untar file" and can be expressed as applications. So such variations can exist. > >> It would be nice if some kind of such specification (probably with >> another entities but with the idea of abstraction of application) is >> described in the JSDL spec. > >I believe it is. Aside from the very standard kinds of execution scheme >(like "run this executable") we also have some more sophisticated ideas >like mechanisms for invokation of Java programs, running of SQL queries >or even invokation of webservices. However, one of the things we still >need to do is to fill out the (non-normative?) specification of how >these things will be done. > >Hope this helps. Thanks. Alexander > >Donal. >

3 3

Revised and updated jsdl xsd schema
by A Stephen McGough 25 Nov '04

25 Nov '04

All, I've attached the latest and updated schema. There are two major changes. 1) Trivial - uses the latest Regular Expression for range values. 2) Big change: removal of jsdl:any and replacement with xsd:any##other. This is due to some big problems with the jsdl:any type. I'm going to put a summary below: a) It was noticed that the requirement for jsdl:any to always have an id tag was inconsistent with the rest of the document. We have stated for the rest of the document that an id tag was only needed when the multiplicity of an element (in the schema) is greater than 1. Thus forcing all extensions to the schema to have an id is incorrect. b) The definition that was there for jsdl:any did not match how I and (I think) most others expected it to work. Here is how I expected it to work: ... <jsdl:Resource> <jsdl:CPUTime operator="lessThanEqualTo">1000</jsdl:CPUTime> <globus:two_phase id="globusExtend">1</globus:two_phase> </jsdl:Resource> ... While in fact the document would need to look like the following: ... <jsdl:Resource> <jsdl:CPUTime operator="lessThanEqualTo">1000</jsdl:CPUTime> <jsdl:any id="globusExtend"> <globus:two_phase>1</globus:two_phase> </jsdl:any> </jsdl:Resource> ... This reduces the elegance of the document and makes it much harder to write. Michel, Nathalie, Willam, Donal and I have had a look at alternatives including using substitution groups and extending jsdl elements and all have some form of drawback which is either as bad if not worse than the fact we can't force people to use an id tag in their elements. As it has now been noticed that id tags don't always need to be there it seems much better to stick with the xsd:any##other tag in the schema and place into the spec document instructions on how extensions should be done and where id attributes should be placed. If someone could put the schema up on GridForge that would be great. Andreas - could you update the pseudo-schema in the document to use xsd:any##other rather than jsdl:any and we'll need to write the section in the spec to describe how to do extensions. steve.. PS if any XML guru knows how to achieve these rules in a schema please let us know. -- ------------------------------------------------------------------------ Dr A. Stephen McGough ------------------------------------------------------------------------ Research Associate, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8310 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------

1 0

FW: BOUNCE jsdl-wg@ggf.org: Non-member submission from ["Lukichev, Alexander S" <alexander.s.lukichev@intel.com>]
by Darren Pulsipher 25 Nov '04

25 Nov '04

-----Original Message----- From: owner-jsdl-wg(a)ggf.org [mailto:owner-jsdl-wg@ggf.org] Sent: Thursday, November 25, 2004 02:35 To: owner-jsdl-wg(a)ggf.org Subject: BOUNCE jsdl-wg(a)ggf.org: Non-member submission from ["Lukichev, Alexander S" <alexander.s.lukichev(a)intel.com>] >From owner-grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov Thu Nov 25 03:35:21 2004 Return-Path: <owner-grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov> X-Original-To: grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov Delivered-To: grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov Received: from localhost (localhost.localdomain [127.0.0.1]) by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id A916412BE4 for <grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov>; Thu, 25 Nov 2004 03:35:21 -0600 (CST) Received: from mailbouncer.mcs.anl.gov ([127.0.0.1]) by localhost (mailbouncer.mcs.anl.gov [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31473-05 for <grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov>; Thu, 25 Nov 2004 03:35:20 -0600 (CST) X-Greylist: delayed 1205 seconds by postgrey-1.16 at mailbouncer.mcs.anl.gov; Thu, 25 Nov 2004 03:35:19 CST Received: from petasus.ims.intel.com (petasus.ims.intel.com [62.118.80.130]) by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id 01CD912BE3 for <jsdl-wg(a)gridforum.org>; Thu, 25 Nov 2004 03:35:19 -0600 (CST) Received: from mssmsxvs01.ims.intel.com (mssmsxvs01.ims.intel.com [10.125.2.23]) by petasus.ims.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id iAP9Ix9w004344 for <jsdl-wg(a)gridforum.org>; Thu, 25 Nov 2004 09:19:00 GMT Received: from mssmsx331.ccr.corp.intel.com ([10.125.2.16]) by mssmsxvs01.ims.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004112512151116895 for <jsdl-wg(a)gridforum.org>; Thu, 25 Nov 2004 12:15:11 +0300 Received: from mssmsx403.ccr.corp.intel.com ([10.125.2.52]) by mssmsx331.ccr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Nov 2004 12:15:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: application abstraction in JSDL Date: Thu, 25 Nov 2004 12:15:10 +0300 Message-ID: <6EDC9204B3704C4C8522539D5C1185E565095C(a)mssmsx403.ccr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: application abstraction in JSDL Thread-Index: AcTSz0MQhfLvcUxLQAaSW8PGwRyBSA== From: "Lukichev, Alexander S" <alexander.s.lukichev(a)intel.com> To: <jsdl-wg(a)gridforum.org> Cc: "Ratering, Ralf" <ralf.ratering(a)intel.com>, "Kentemich, Thomas" <thomas.kentemich(a)intel.com>, "Petrov, Dmitry N" <dmitry.n.petrov(a)intel.com>, "Odintsov, Igor O" <igor.o.odintsov(a)intel.com> X-OriginalArrivalTime: 25 Nov 2004 09:15:11.0261 (UTC) FILETIME=[43E8CCD0:01C4D2CF] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailbouncer.mcs.anl.gov X-Spam-Status: No, hits=0.0 tagged_above=-1.0 required=5.0 tests= X-Spam-Level: Hi, Our team is currently develops an application that will use JSDL documents as input to invoke jobs in a distributed system. I'd like to comment if possible some aspects of the latest JSDL=20 schema. Currently to describe the job to run you can specify: a) executable name b) arguments c) environment variables This could be not enough configurable because executables can reside at different places on the different systems, arguments can be passed in different ways to close applications on=20 different systems, etc. Thus JSDL contains pretty enough=20 information for locating the suitable server, the located server=20 could fail to run the requested application because of lack of=20 configuration information. We can look at the UNICORE experience and try to configure the particular applications using the following entities: a) fields (i.e. partucular file names, argument values,=20 e.g. "source=3Da.c", "size=3D1234") b) options (i.e. names for common modes of application=20 work; though setting this mode could differ from=20 system to system, e.g. "debug=3Don" results in passing=20 "-g" to some compilers) c) contexts (modes for application invocations, e.g.=20 "profiliration") d) variations (variations of expected results, e.g.=20 "overwrite" for file operations) It would be nice if some kind of such specification (probably with another entities but with the idea of abstraction of application) is described in the JSDL spec. Thanks. Alexander

1 0

application abstraction in JSDL (fwd)
by Ali Anjomshoaa 25 Nov '04

25 Nov '04

Fwding bounced mail... -- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali(a)epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 ------------------------------------------------------------- ---------- Forwarded message ---------- Date: Thu, 25 Nov 2004 12:15:10 +0300 From: "Lukichev, Alexander S" <alexander.s.lukichev(a)intel.com> To: jsdl-wg(a)gridforum.org Cc: "Ratering, Ralf" <ralf.ratering(a)intel.com>, "Kentemich, Thomas" <thomas.kentemich(a)intel.com>, "Petrov, Dmitry N" <dmitry.n.petrov(a)intel.com>, "Odintsov, Igor O" <igor.o.odintsov(a)intel.com> Subject: application abstraction in JSDL Hi, Our team is currently develops an application that will use JSDL documents as input to invoke jobs in a distributed system. I'd like to comment if possible some aspects of the latest JSDL schema. Currently to describe the job to run you can specify: a) executable name b) arguments c) environment variables This could be not enough configurable because executables can reside at different places on the different systems, arguments can be passed in different ways to close applications on different systems, etc. Thus JSDL contains pretty enough information for locating the suitable server, the located server could fail to run the requested application because of lack of configuration information. We can look at the UNICORE experience and try to configure the particular applications using the following entities: a) fields (i.e. partucular file names, argument values, e.g. "source=a.c", "size=1234") b) options (i.e. names for common modes of application work; though setting this mode could differ from system to system, e.g. "debug=on" results in passing "-g" to some compilers) c) contexts (modes for application invocations, e.g. "profiliration") d) variations (variations of expected results, e.g. "overwrite" for file operations) It would be nice if some kind of such specification (probably with another entities but with the idea of abstraction of application) is described in the JSDL spec. Thanks. Alexander

2 1

RE: Some comments on the Schema & first draft of XSD v.1.0
by Michel Drescher 24 Nov '04

24 Nov '04

Guys, here's my spam again: > General note: This has brought a large number of > inconsistencies in the > document to light. Michel you seem to have used the psudo-schema in > order to write your version while I used the other parts of the > document. These discrepencies need to be resolved. For now I've stuck > with the document rather than the psudo-schema unless the > psudo-schema makes much more sense. Yes, indeed, I used the pseudo-schema. Although Dave kept track of it through the meeting, I didn't have it available when I started writing my schema version (since that was yesterday evening at home... *g*). Hence I compiled my own pseudo-schema based on the snippets given in the spec document posted on http://forge.gridforum.org on last Friday (thanks, Andreas!). This prep-step was quite enlightning since it really brightly demonstrated where contradictions within the document are/were (didn't keep track of these) and that the pseudo-schema truly builds up from modules. I started with the pseudo-schema on top level in pathetic notepad.exe, and replaced rough-defined elements (i.e. <User .../>) with the more detailed or completed versions given at their respective definition as I walked the document from top to bottom. > >Dear Stephen (and fellow mailing list members), > > > >I couldn't help but mess arount with JSDL as well - and here > is my result. Use whatever you can use. :-) > >Some things I spotted in your version (and mine), who are > also of general interest: > > > > > Thanks for doing this - I knew there would be errors in this - was > getting schema blind and couldn't spot them! I know how that feels :-) Below, I only refer to things that you did not already changed so it gives a nice "to do" list. > >(1) JobDescription > >You give xsd:anyType as type for the any element, the spec > >says xsd:any##other? > > > Erm, In the copy of the Schema I have here (the one from the end of > Friday) it has a jsdl:any in JobDescription. That seems to be what I > have in the schema. I downloaded my copy yesterday evening - maybe Andreas already changed the document since Friday? > >(4) Application > >Your schema defines AplicationDescription to be unbounded, > the spec states it's optional? > > > I had this as unbounded as all other Description elements in > the schema are unbounded. Happy to change it to optional. Though > we should beconsistent over the document. Funny enough, I reckognised in my pseudo-schema all description elements as optional. But we definitely need to be consistent in dhe spec document AND the schema. However, I incline to have all descriptions optional (and not unbounded). > >(8) FileSystem.DiskSpace > >You give xsd:positiveInteger as type, while the spec states > jsdl:rangeValue? (I'd prefer the latter) > > > > > Spec discrepency! psudo-schema and doc don't match > The spec seems to have xsd:positiveInteger as the type. > However, as we have an operator on this element does it > make sense to change it to a range? I can understand > "-10Gb" or "20Gb-" but do the following make sense? > "10Gb, 20Gb, 80Gb"? I definitely second to have a range here. I think even the given list may make sense - if the application is written to support this (who does this?!?). Anyway, if we allow for a rangeValue here, the spec must give more detail on how a consuming system MAY react on funny values. > >(11) DataStaging.FileSystemID > >The spec defines this to be required, you define it as optional? > > > Spec discrepency! psudo-schema and doc don't match > Ah, there's an inconsistency in the document here. The > Multiplicity is marked as 0-1 while the psudo-schema has > it manditory. Presumably we used the respective forms. > I'd say this item should be optional. We need > to make a decision on this and match the two up. In ch 5.6.3.1 the definition clearly marks this as optional: "If the FileSystemID is specified then the FileName is relative to the specified FileSystem declaration referenced by the id. In this case there MUST also be a FileSystem Element with the same id. Otherwise the FileName is relative to the working job directory as specified by WorkingDirectory element." So I think the pseudo-schema is wrong at this point. > >(13) limitUnits [Quote reformatted due to MS Outlook comb quoting... argh!] > [...] > Yes this is a big problem with XML schema's. However, this > problem goes across the board. Anywhere where we specify a > string (or arbitary token) we can put in any form of > gibberish. For example the following fragment > is valid XML (and in some case may also be a valid job) > <jsdl:Executable>The Cat Sat on the mat</jsdl:Executable> > I don't think XSD can tie down all cases. So it's reasonable to allow > the consumer to throw your example (and or mine). > Hopefully a later schema definition language than XSD will > allow these things to be checked. Yes I know. I just wanted to stress that point - and to give Andreas some more work with the spec document, to add this kind of interpretation. ;-) > >(15) ApplicationTypeEnumeration, > ProcessorArchitecture(Type)Enumeration, > FileSystemTypeEnumeration, OperatingSystemTypeEnumeration, > CreationFlagEnumeration, LimitTypeEnumeration > >Almost all of them have an empty jsdl:token restriction too > many, that have no function but bloat the schema. > Additionally, I'd propose to use xsd:NMTOKEN as type, which > does not allow whitespaces. This collides with the current > enumerations (especially OperatingSystemTypeEnumeration), but > offers a stricter definition. xsd:token is "too relaxed" in > my opinion. Additionally, please align the naming, your > ProcessorArchitectureEnumeration is missing a "Type" in > between (sorry for being pedantic here ;-) > > > Ah, is this the <xsd:union memberTypes="xsd:token"> right at > the start of each of them? If so this is needed to allow people > to add to the list. If you don't then the list that we send out > can't be extended - or at least that's what the XSD document I > read claimed. Anyone have a more definative answer to that one? Exactly, it is. I didn't think of the extensibility, though. I read the respective paragraphs in the spec document (like, 5.5.13.5, "This token can be extended as additional types are identified.") the way that the JSDL WG emends that list as there is a need for more, and publish a new version of the document. Any other comments on that? > >(17) Ids used in the schema > >XML Schema offers two types to use for ids and to reference > them in a XML document: > >xsd:ID - http://books.xmlschemata.org/relaxng/ch17-77096.html > >xsd:IDREF - http://books.xmlschemata.org/relaxng/ch17-77101.html > >and even > >xsd:IDREFS - http://books.xmlschemata.org/relaxng/ch17-77106.html > >I think these are exactly the types we were looking for and > are a perfect match for our schema, wherever we use the Id > attribute for elements, I suppose. > > > > > Where exactly are you proposing these are used? Just for the whole > document or at each unbounded element? I see you have xsd:ID for the > document. If this is the only place then fine. I've updated the other > schema to match. I thought to use them as a replacement for xsd:NCName where it is used as a defining identifier, i.e. in the DataStaging element. What I just realised is that we then cannot re-use the elements of JobDescriptionSection to be also a sub-element of Profile, because then the id of type xsd:ID of, say, a DataStaging element in a Profile section MUST be different from a DataStaging element in the JobDescriptionSection element even if I wanted to supersede it. This violates the specification, unless you XSD gurus find a way to use/allow/force xsd:IDREF when the according element is a sub-element of a Profile element. After all, this leaves 7 quirky things, if I did not overlook others. We're closing in on the finish line! Cheers, Michel

3 2

Version 1.0 of the XSD Schema for JSDL
by A Stephen McGough 24 Nov '04

24 Nov '04

All, Attached is the XSD Schema defined at the face-to-face meeting held in London on the 17-19th November 2004. This schema should be read in conjunction with the JSDL draft document that came out of this meeting and is available on GridForge. As always please try out the schema and let the list know of your experiences. We'd be particularly interested in those people who try to describe jobs they normally use vendor DRM systems for. What extensions do you require to describe your jobs and how easy is it to describe the jobs. Many thanks, steve.. -- ------------------------------------------------------------------------ Dr A. Stephen McGough ------------------------------------------------------------------------ Research Associate, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8310 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------

3 8

Actions from the F2F
by Andreas Savva 24 Nov '04

24 Nov '04

As promised here is a cleaned up list of actions from the (still) draft minutes. Thanks to all who participated in the f2f last week. Some actions don't have people assigned to them. In particular would people working on the schema check whether there are any issues listed here that they would like to take on? If there is anything missing or any new items please mail the list (or me) and I will add it to the actions. ================= JSDL F2F Actions: ================= 0. Andreas to clean up document by the next teleconf. 1. Use the figures from Steve's presentation and add text to the spec under purpose/scope, in particular describe how the 'things' outside the JSDL box fit in. (E.g, agreement, policy, workflow, etc.) - Andreas,Steve,Darren 2. Provide a non-normative example for the other type of refinement (aka enrichment) of adding profiles to a job document. 3. Add the full version of the normative schema in the appendix (in addition to the pseudo schema description) - Pending on full schema definition 4. Add more examples to the document. The following people were identified: - Unicore(Michel, Sven), gridMatrix(Darren), Condor(Steve) LSF (Chris), SGE(Dan), Business grid (Andreas), PBS(Bill), Naregi(Saga), Globus(Nathalie) - Darren to contact Bill 5. Review and cross-check type information between schema and specification after the document is cleaned up and any immediate problems with the schema are fixed. - Agenda item for first teleconf. 6. Applying preference to profiles. Profiles are named and it is expected that preference can be applied to them by an outside framework, e.g., WS-Agreement. - Andreas to do a WS-Agreement example 7. How to invoke a Web service application type - Fred to provide an example WS invocation 8. Give an example extension for software requirements (e.g., required libraries). During the F2F we agreed these would be under the resource section. 9. Agreed to define "Description" as a general element to be inherited by all elements. - Steve to work in the schema - Andreas to add explanation in the specification 10. Discuss jsdl compliance levels - A teleconf agenda item 11. Add an extensibility example for (disk) performance or availability to be addressed. Use the provided extensibility point. 12. Review naming of elements for consistency. - Andreas to do as part of document cleanup. 13. Agreed to allow operators only in places where they make sense. - Andreas to do first pass as part of document cleanup (but others can try to do this too as part of schema refinement) 14. Mounting remote resource to a local location: is this configuration (out of scope) or do we need to do something about it. - Steve to come up with motivating examples. 15. Define 'unlimited' value for limits 16. Dave to do pseudo-code for the profile processing rules 17. Sven to do examples for the profile processing rules 18. Add text on how to write a jsdl document (at a later stage when we understand things better) 19. Chris to provide text to motivate and describe the model for processTopology 20. Andreas to add boilerplate text in Security section 21. Andreas to add people in Contributors section - Send your name to Andreas if you think you should be added under Contributors. 22. Revisit xsd:token usage and decide if we want to define new types - Agreed to define new types to replace xsd:tokens. - (People working on schema please check) 23. What are the semantics for an extension that is not supported by a system: reject or ignore? Possible need to add explanatory text. - Andreas to check during document cleanup. -- Andreas Savva Fujitsu Laboratories Ltd.

1 0

RE: [Fwd: Re: [jsdl-wg] Latest XSD schema - as of 23rd November 2004 (last one for today!)]
by Michel Drescher 23 Nov '04

23 Nov '04

I got the messages without any problems - only Nathalie's mail didn't come through, only as the forward from Darren (thanks!) Cheers, Michel -----Original Message----- From: owner-jsdl-wg(a)ggf.org [mailto:owner-jsdl-wg@ggf.org] On Behalf Of A Stephen McGough Sent: Tuesday, November 23, 2004 5:17 PM To: JSDL WG Subject: [Fwd: Re: [jsdl-wg] Latest XSD schema - as of 23rd November 2004 (last one for today!)] All, There seems to be a problem with the mailsystem. Has anyone else noticed it? Nathalie and william are having their mail bounced. Here is Williams last message. steve.. -------- Original Message -------- Subject: Re: [jsdl-wg] Latest XSD schema - as of 23rd November 2004 (last one for today!) Date: Tue, 23 Nov 2004 16:45:21 +0000 From: William Lee <wwhl(a)doc.ic.ac.uk> <mailto:wwhl@doc.ic.ac.uk> To: Steve McGough <asm100(a)doc.ic.ac.uk> <mailto:asm100@doc.ic.ac.uk> My mail is not appearing on the list. Maybe it has bounced. Do you have access to the JSDL mailinglist system? ------------------------------ I agreed that Qname type can be used, however, it's been a controversial type to use throughout the history of XSD, because interpretation of a QName value needs contextual information (the enclosing elements and their xmlns declaration). <jsdl:JobDefinition ...> ... <jsdl:CPUArchitecture>myns:sparc</jsdl:CPUArchitecture> ... </jsdl:JobDefinition> For the parser, it needs to resolve the "myns" namespace prefix from the enclosing elements in order to deduce whether it's in the jsdl namespace or others. I'm easy both ways (token / qname), although I don't think going Qname makes the definition any richer. I just want to point out the argument from an implementers' point of view. William ------------------------------ --- William Lee [Software Coordinator] @ London e-Science Centre ------- A: Room 348, Department of Computing, Imperial College London, Huxley Building, South Kensington campus, London SW7 2AZ, UK E: wwhl(a)doc.ic.ac.uk | william(a)imageunion.com W: www.lesc.ic.ac.uk | www.imageunion.com P: +44(0)20 7594 8251 F: +44(0)20 7581 8024 --- Projects ---------------------------- GridSAM: http://www.lesc.ic.ac.uk/gridsam Markets: http://www.lesc.ic.ac.uk/markets ICENI: http://www.lesc.ic.ac.uk/iceni ----------------------------------------- -- ------------------------------------------------------------------------ Dr A. Stephen McGough ------------------------------------------------------------------------ Research Associate, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8310 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------

1 0

[Fwd: Re: [jsdl-wg] Latest XSD schema - as of 23rd November 2004 (last one for today!)]
by A Stephen McGough 23 Nov '04

23 Nov '04

All, There seems to be a problem with the mailsystem. Has anyone else noticed it? Nathalie and william are having their mail bounced. Here is Williams last message. steve.. -------- Original Message -------- Subject: Re: [jsdl-wg] Latest XSD schema - as of 23rd November 2004 (last one for today!) Date: Tue, 23 Nov 2004 16:45:21 +0000 From: William Lee <wwhl(a)doc.ic.ac.uk> To: Steve McGough <asm100(a)doc.ic.ac.uk> My mail is not appearing on the list. Maybe it has bounced. Do you have access to the JSDL mailinglist system? ------------------------------ I agreed that Qname type can be used, however, it's been a controversial type to use throughout the history of XSD, because interpretation of a QName value needs contextual information (the enclosing elements and their xmlns declaration). <jsdl:JobDefinition ...> ... <jsdl:CPUArchitecture>myns:sparc</jsdl:CPUArchitecture> ... </jsdl:JobDefinition> For the parser, it needs to resolve the "myns" namespace prefix from the enclosing elements in order to deduce whether it's in the jsdl namespace or others. I'm easy both ways (token / qname), although I don't think going Qname makes the definition any richer. I just want to point out the argument from an implementers' point of view. William ------------------------------ --- William Lee [Software Coordinator] @ London e-Science Centre ------- A: Room 348, Department of Computing, Imperial College London, Huxley Building, South Kensington campus, London SW7 2AZ, UK E: wwhl(a)doc.ic.ac.uk | william(a)imageunion.com W: www.lesc.ic.ac.uk | www.imageunion.com P: +44(0)20 7594 8251 F: +44(0)20 7581 8024 --- Projects ---------------------------- GridSAM: http://www.lesc.ic.ac.uk/gridsam Markets: http://www.lesc.ic.ac.uk/markets ICENI: http://www.lesc.ic.ac.uk/iceni ----------------------------------------- -- ------------------------------------------------------------------------ Dr A. Stephen McGough ------------------------------------------------------------------------ Research Associate, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8310 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------

1 0

RE: [jsdl-wg] Version 1.0 of the XSD Schema for JSDL
by Michel Drescher 23 Nov '04

23 Nov '04

Stephen, Donal and others, please see my comments interweaved below. > [...] > What is the difference between xsd:QName and xsd:NMTOKEN? > We've changed things over to xsd:NMTOKEN. It's easy to > change to xsd:QName but I think we need to know why. xsd:QName is a qualified XML name in respect that its local name part is of type xsd:NCName and allows for a namespace qualifier (like jsdl). It is thus a xsd:NCName extension (that doesn't allow for whitespaces either) with the optional ':' to form something like "jsdl:storageUnits". I suppose xsd:QName is not needed for enumerations that we do not want to be extended by users (i.e. jsdlVersion). Since xsd:NMTOKEN allows for characters, digits, ".", ":" and "-", it forms IMHO a superclass (in terms of power, not formal inheritance) of xsd:QName. Cheers, Michel

1 0