- jsdl-wg - lists.ogf.org

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

Latest XSD schema - as of 23rd November 2004 (last one for today!)
by A Stephen McGough 23 Nov '04

23 Nov '04

Attached is the updated XSD schema. I think I've rolled in all the requests I've had so far. It's great to see so much enthusiasm and interest in this. As usual let me know what you think of it. 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 ------------------------------------------------------------------------

1 0

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

23 Nov '04

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: (1) JobDescription You give xsd:anyType as type for the any element, the spec says xsd:any##other? (2) Profile The id attribute is xsd:anyURI, didn't we agree to use xsd:NCName for all IDs? (3) Application The doc states that Application has NO id, your schema defines one? (4) Application Your schema defines AplicationDescription to be unbounded, the spec states it's optional? (5) HostSpecificEnvironment Residual from old spec? (6) EnvironmentVariables Residual from old spec? (7) Resource The spec defines xsd:any##other as extension mechanism, you use xsd:anyType? (8) FileSystem.DiskSpace You give xsd:positiveInteger as type, while the spec states jsdl:rangeValue? (I'd prefer the latter) (9) Network Residual from old spec? (Resource element defines its own NetworkBandwidth element...) (10) DataStaging It misses the id attribute? (11) DataStaging.FileSystemID The spec defines this to be required, you define it as optional? (12) frequencyUnits, bandwidthUnits, operator, storageUnits, limitValue I'd propose to use xsd:NMTOKEN as type, as this does not allow whitespaces (I'd prefer that). (13) limitUnits It's a nice solution (mine was way more lame). However, it's missing time elements (for CPUTime, wallTime, etc) and simple integers (for openDescriptors etc). However, we have a "definition hole" in here. Consider the following XML snippet: <jsdl:JobDescription> <jsdl:Limits> <jsdl:Limit jsdl:name="CPUTime" jsdl:units="hour">33</jsdl:Limit> <jsdl:Limit jsdl:name="virtualMemory" jsdl:units="GB">16</jsdl:Limit> <jsdl:Limit jsdl:name="openDescriptors" jsdl:units="integer">159</jsdl:Limit> <jsdl:Limit jsdl:name="fileSize" jsdl:units="day">666</jsdl:Limit> </jsdl:Limits> </jsdl:JobDescription> While this validates against the schema (with my version of the limitUnits type), the "fileSize" limit definition has a major flaw... We either keep the elegant and short schema definition as it is now for Limits and Limit and specify in the spec document, that "the consuming system MUST interpret a Limit element's units and name attributes according to meaningful values. Otherwise the JSDL document MUST be rejected." Or, we bloat up the schema with distinct Limit subelements. You pick the poison... (14) rangeValue this regular expression looks ugly ;-) Can we use '\d' to describe decimal letters? Makes the expression easier to read... (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 ;-) (16) jsdl:any My solution is completely different to yours - I have no clue why. Can you enlighten me, please? :-) (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. Again, thank you guys for a remarkable productive F2F meeting at Imperial College! Cheers, Michel

2 1

FW: BOUNCE jsdl-wg@ggf.org: Non-member submission from [Nathalie Furmento <n.furmento@doc.ic.ac.uk>]
by Darren Pulsipher 23 Nov '04

23 Nov '04

-----Original Message----- From: owner-jsdl-wg(a)ggf.org [mailto:owner-jsdl-wg@ggf.org] Sent: Tuesday, November 23, 2004 08:02 To: owner-jsdl-wg(a)ggf.org Subject: BOUNCE jsdl-wg(a)ggf.org: Non-member submission from [Nathalie Furmento <n.furmento(a)doc.ic.ac.uk>] >From owner-grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov Tue Nov 23 09:02:03 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 883D712BEA for <grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov>; Tue, 23 Nov 2004 09:02:03 -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 30725-09 for <grdfm-jsdl-wg(a)mailbouncer.mcs.anl.gov>; Tue, 23 Nov 2004 09:02:01 -0600 (CST) X-Greylist: delayed 5223 seconds by postgrey-1.16 at mailbouncer.mcs.anl.gov; Tue, 23 Nov 2004 09:02:01 CST Received: from roadrunner.doc.ic.ac.uk (roadrunner.doc.ic.ac.uk [146.169.1.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id 5963012B04 for <jsdl-wg(a)gridforum.org>; Tue, 23 Nov 2004 09:02:01 -0600 (CST) Received: from chestnut.doc.ic.ac.uk ([146.169.6.28]) by roadrunner.doc.ic.ac.uk with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1CWaoq-0006o3-QV for jsdl-wg(a)gridforum.org; Tue, 23 Nov 2004 13:34:56 +0000 Received: from nfur by chestnut.doc.ic.ac.uk with local (Exim 4.20) id 1CWaoq-00010Y-P0 for jsdl-wg(a)gridforum.org; Tue, 23 Nov 2004 13:34:56 +0000 Date: Tue, 23 Nov 2004 13:34:56 +0000 From: Nathalie Furmento <n.furmento(a)doc.ic.ac.uk> To: JSDL WG <jsdl-wg(a)gridforum.org> Subject: Re: [jsdl-wg] Version 1.0 of the XSD Schema for JSDL Message-ID: <20041123133456.GA3863(a)doc.ic.ac.uk> References: <41A312FA.4020706(a)doc.ic.ac.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <41A312FA.4020706(a)doc.ic.ac.uk> User-Agent: Mutt/1.4.1i X-Url: http://www.doc.ic.ac.uk/~nfur/ Sender: Nathalie Furmento <nfur(a)doc.ic.ac.uk> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailbouncer.mcs.anl.gov --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline All, The xsd:pattern for the rangeValue is incorrect. The expression 0-9 must be inside [] to mean any digit. I attach the corrected version. Cheers, Nathalie On Nov 23, 10:37, A Stephen McGough wrote: > 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 > ---------------------------------------------------------------------- > -- -- ----------------------------------------------------------------------- Dr Nathalie Furmento Research Associate, London E-Science Centre Department of Computing, South Kensington Campus tel: +44 207-594-8409 Imperial College London, London SW7 2AZ, UK fax: +44 207-581-8024 ----------------------------------------------------------------------- --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="jsdl-1.0.xsd" <?xml version="1.0" encoding="UTF-8"?>  <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.gridforum.org/JSDL" targetNamespace="http://www.gridforum.org/JSDL" elementFormDefault="qualified">  <xsd:simpleType name="jsdlVersion" final="#all"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="v1.0"/>  </xsd:restriction> </xsd:simpleType>   <xsd:simpleType name="frequencyUnits"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="Hz"/> <xsd:enumeration value="kHz"/> <xsd:enumeration value="MHz"/> <xsd:enumeration value="GHz"/> <xsd:enumeration value="THz"/> <xsd:enumeration value="PHz"/> <xsd:enumeration value="EHz"/> </xsd:restriction> </xsd:simpleType>  <xsd:simpleType name="bandwidthUnits"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="bps"/> <xsd:enumeration value="Kbps"/> <xsd:enumeration value="Mbps"/> <xsd:enumeration value="Gbps"/> <xsd:enumeration value="Tbps"/> <xsd:enumeration value="Pbps"/> <xsd:enumeration value="Ebps"/> </xsd:restriction> </xsd:simpleType>  <xsd:simpleType name="operator"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="equalTo"/> <xsd:enumeration value="notEqualTo"/> <xsd:enumeration value="moreThan"/> <xsd:enumeration value="moreThanEqualTo"/> <xsd:enumeration value="lessThan"/> <xsd:enumeration value="lessThanEqualTo"/> <xsd:enumeration value="match"/> <xsd:enumeration value="notMatch"/> </xsd:restriction> </xsd:simpleType>  <xsd:simpleType name="storageUnits"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="B"/> <xsd:enumeration value="KB"/> <xsd:enumeration value="MB"/> <xsd:enumeration value="GB"/> <xsd:enumeration value="TB"/> <xsd:enumeration value="PB"/> <xsd:enumeration value="EB"/> </xsd:restriction> </xsd:simpleType>  <xsd:simpleType name="limitUnits"> <xsd:union memberTypes="frequencyUnits bandwidthUnits storageUnits"/> </xsd:simpleType>  <xsd:simpleType name="limitValue"> <xsd:union memberTypes="xsd:nonNegativeInteger"> <xsd:simpleType> <xsd:restriction base="xsd:token"> <xsd:enumeration value="unlimited"/> </xsd:restriction> </xsd:simpleType> </xsd:union> </xsd:simpleType>  <xsd:simpleType name="rangeValue"> <xsd:restriction base="xsd:string"> <xsd:pattern value="( *-? *[0-9]+ *-? *[0-9]* *,? *)+"/> </xsd:restriction> </xsd:simpleType>  <xsd:simpleType name="ApplicationTypeEnumeration"> <xsd:union memberTypes="xsd:token"> <xsd:simpleType> <xsd:restriction base="xsd:token"> <xsd:enumeration value="executable"/> <xsd:enumeration value="sh"/> <xsd:enumeration value="csh"/> <xsd:enumeration value="ksh"/> <xsd:enumeration value="bash"/> <xsd:enumeration value="tcsh"/> <xsd:enumeration value="perl"/> <xsd:enumeration value="tcl"/> <xsd:enumeration value="python"/> <xsd:enumeration value="java"/> <xsd:enumeration value="sql"/> <xsd:enumeration value="webService"/> </xsd:restriction> </xsd:simpleType> </xsd:union> </xsd:simpleType>  <xsd:simpleType name="ProcessorArchitectureEnumeration"> <xsd:union memberTypes="xsd:token"> <xsd:simpleType> <xsd:restriction base="xsd:token"> <xsd:enumeration value="sparc"/> <xsd:enumeration value="powerpc"/> <xsd:enumeration value="x86"/> <xsd:enumeration value="parisc"/> <xsd:enumeration value="mips"/> <xsd:enumeration value="ia86"/> <xsd:enumeration value="arm"/> </xsd:restriction> </xsd:simpleType> </xsd:union> </xsd:simpleType>  <xsd:simpleType name="FileSystemTypeEnumeration"> <xsd:union memberTypes="xsd:token"> <xsd:simpleType> <xsd:restriction base="xsd:token"> <xsd:enumeration value="swap"/> <xsd:enumeration value="tmp"/> <xsd:enumeration value="spool"/> <xsd:enumeration value="normal"/> </xsd:restriction> </xsd:simpleType> </xsd:union> </xsd:simpleType>  <xsd:simpleType name="OperatingSystemTypeEnumeration"> <xsd:union memberTypes="xsd:token"> <xsd:simpleType> <xsd:restriction base="xsd:token"> <xsd:enumeration value="Unknown"/> <xsd:enumeration value="Other"/> <xsd:enumeration value="MACOS"/> <xsd:enumeration value="ATTUNIX"/> <xsd:enumeration value="DGUX"/> <xsd:enumeration value="DECNT"/> <xsd:enumeration value="Tru64_UNIX"/> <xsd:enumeration value="OpenVMS"/> <xsd:enumeration value="HPUX"/> <xsd:enumeration value="AIX"/> <xsd:enumeration value="MVS"/> <xsd:enumeration value="OS400"/> <xsd:enumeration value="OS/2"/> <xsd:enumeration value="JavaVM"/> <xsd:enumeration value="MSDOS"/> <xsd:enumeration value="WIN3x"/> <xsd:enumeration value="WIN95"/> <xsd:enumeration value="WIN98"/> <xsd:enumeration value="WINNT"/> <xsd:enumeration value="WINCE"/> <xsd:enumeration value="NCR3000"/> <xsd:enumeration value="NetWare"/> <xsd:enumeration value="OSF"/> <xsd:enumeration value="DC/OS"/> <xsd:enumeration value="Reliant_UNIX"/> <xsd:enumeration value="SCO_UnixWare"/> <xsd:enumeration value="SCO_OpenServer"/> <xsd:enumeration value="Sequent"/> <xsd:enumeration value="IRIX"/> <xsd:enumeration value="Solaris"/> <xsd:enumeration value="SunOS"/> <xsd:enumeration value="U6000"/> <xsd:enumeration value="ASERIES"/> <xsd:enumeration value="TandemNSK"/> <xsd:enumeration value="TandemNT"/> <xsd:enumeration value="BS2000"/> <xsd:enumeration value="LINUX"/> <xsd:enumeration value="Lynx"/> <xsd:enumeration value="XENIX"/> <xsd:enumeration value="VM"/> <xsd:enumeration value="Interactive_UNIX"/> <xsd:enumeration value="BSDUNIX"/> <xsd:enumeration value="FreeBSD"/> <xsd:enumeration value="NetBSD"/> <xsd:enumeration value="GNU_Hurd"/> <xsd:enumeration value="OS9"/> <xsd:enumeration value="MACH_Kernel"/> <xsd:enumeration value="Inferno"/> <xsd:enumeration value="QNX"/> <xsd:enumeration value="EPOC"/> <xsd:enumeration value="IxWorks"/> <xsd:enumeration value="VxWorks"/> <xsd:enumeration value="MiNT"/> <xsd:enumeration value="BeOS"/> <xsd:enumeration value="HP_MPE"/> <xsd:enumeration value="NextStep"/> <xsd:enumeration value="PalmPilot"/> <xsd:enumeration value="Rhapsody"/> <xsd:enumeration value="Windows_2000"/> <xsd:enumeration value="Dedicated"/> <xsd:enumeration value="OS/390"/> <xsd:enumeration value="VSE"/> <xsd:enumeration value="TPF"/> <xsd:enumeration value="Windows_(R)_Me"/> <xsd:enumeration value="Caldera_Open_UNIX"/> <xsd:enumeration value="OpenBSD"/> <xsd:enumeration value="Not_Applicable"/> <xsd:enumeration value="Windows_XP"/> <xsd:enumeration value="z/OS"/> <xsd:enumeration value="Microsoft_Windows_Server_2003"/> <xsd:enumeration value="Microsoft_Windows_Server_2003_64-Bit"/> </xsd:restriction> </xsd:simpleType> </xsd:union> </xsd:simpleType>  <xsd:simpleType name="CreationFlagEnumeration"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="overwrite"/> <xsd:enumeration value="append"/> <xsd:enumeration value="prepend"/> </xsd:restriction> </xsd:simpleType>  <xsd:simpleType name="LimitTypeEnumeration"> <xsd:union memberTypes="xsd:token"> <xsd:simpleType> <xsd:restriction base="xsd:token"> <xsd:enumeration value="wallTime"/> <xsd:enumeration value="fileSize"/> <xsd:enumeration value="coreDump"/> <xsd:enumeration value="dataSegment"/> <xsd:enumeration value="lockedMemory"/> <xsd:enumeration value="memory"/> <xsd:enumeration value="openDescriptors"/> <xsd:enumeration value="pipeSize"/> <xsd:enumeration value="stackSize"/> <xsd:enumeration value="CPUTime"/> <xsd:enumeration value="processCount"/> <xsd:enumeration value="virtualMemory"/> <xsd:enumeration value="threadCount"/> </xsd:restriction> </xsd:simpleType> </xsd:union> </xsd:simpleType>  <xsd:simpleType name="description"> <xsd:restriction base="xsd:string"/> </xsd:simpleType>      <xsd:element name="JobDefinition"> <xsd:complexType> <xsd:sequence> <xsd:element ref="JobDescription"/> <xsd:element ref="Profile" minOccurs="0" maxOccurs="unbounded"/> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="jsdlVersion" type="jsdlVersion" use="required"/> <xsd:attribute name="id" type="xsd:ID"/> </xsd:complexType> </xsd:element>  <xsd:element name="JobDescription"> <xsd:complexType> <xsd:sequence> <xsd:element ref="JobIdentification" minOccurs="0"/> <xsd:element ref="User" minOccurs="0"/> <xsd:element ref="Application" minOccurs="0"/> <xsd:element ref="Resource" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="DataStaging" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="Limits" minOccurs="0"/> <xsd:element ref="any" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element>  <xsd:element name="Profile"> <xsd:complexType> <xsd:sequence> <xsd:element name="ProfileDescription" type="xsd:string" minOccurs="0"/> <xsd:element ref="User" minOccurs="0"/> <xsd:element ref="Application" minOccurs="0"/> <xsd:element ref="Resource" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="DataStaging" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="Limits" minOccurs="0"/> <xsd:element ref="any" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:anyURI"/> </xsd:complexType> </xsd:element>  <xsd:element name="JobIdentification"> <xsd:complexType> <xsd:sequence> <xsd:element name="JobName" type="xsd:string" minOccurs="0"/> <xsd:element name="Description" type="description" minOccurs="0"/> <xsd:element name="JobAnnotation" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="JobProject" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>  <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element>  <xsd:element name="Application"> <xsd:complexType> <xsd:sequence> <xsd:element name="ApplicationName" type="xsd:string" minOccurs="0"/> <xsd:element name="ApplicationVersion" type="xsd:string" minOccurs="0"/> <xsd:element name="ApplicationType" type="ApplicationTypeEnumeration" minOccurs="0"/> <xsd:element name="ApplicationDescription" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="Executable" type="xsd:string" minOccurs="0"/> <xsd:element name="Argument" type="xsd:string" minOccurs="0"/> <xsd:element name="Input" type="xsd:string" minOccurs="0"/> <xsd:element name="Output" type="xsd:string" minOccurs="0"/> <xsd:element name="Error" type="xsd:string" minOccurs="0"/> <xsd:element name="WorkingDirectory" type="xsd:string" minOccurs="0"/> <xsd:element ref="Environment" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="TileSize" type="xsd:positiveInteger" minOccurs="0"/> <xsd:element ref="ProcessCount" minOccurs="0"/> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:NCName"/> </xsd:complexType> </xsd:element>  <xsd:element name="User"> <xsd:complexType> <xsd:sequence> <xsd:element name="UserCredential" type="xsd:anyType" minOccurs="0"/> <xsd:element name="ExecutionUserID" type="xsd:string" minOccurs="0"/> <xsd:element name="ExecutionGroupID" type="xsd:string" minOccurs="0"/> <xsd:element ref="UserGroup" minOccurs="0" maxOccurs="unbounded"/> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element>  <xsd:element name="Environment"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="id" type="xsd:NCName"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  <xsd:element name="HostSpecificEnvironment"> <xsd:complexType> <xsd:attribute name="name" type="xsd:string"/> </xsd:complexType> </xsd:element>  <xsd:element name="EnvironmentVariables"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="name" type="xsd:string"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  <xsd:element name="OperatingSystem"> <xsd:complexType> <xsd:sequence> <xsd:element name="OperatingSystemType" type="OperatingSystemTypeEnumeration" minOccurs="0"/> <xsd:element name="OperatingSystemVersion" type="xsd:string" minOccurs="0"/> <xsd:element name="OperatingSystemDescription" type="xsd:string" minOccurs="0"/> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element>  <xsd:element name="Limits"> <xsd:complexType> <xsd:sequence> <xsd:element ref="Limit" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element>  <xsd:element name="Resource"> <xsd:complexType> <xsd:sequence> <xsd:element name="HostName" type="xsd:string" minOccurs="0"/> <xsd:element name="CPUArchitecture" type="ProcessorArchitectureEnumeration" minOccurs="0"/> <xsd:element ref="CPUSpeed" minOccurs="0"/> <xsd:element ref="CPUTime" minOccurs="0"/> <xsd:element ref="CPUCount" minOccurs="0"/> <xsd:element ref="ResourceCount" minOccurs="0"/> <xsd:element ref="PhysicalMemory" minOccurs="0"/> <xsd:element ref="VirtualMemory" minOccurs="0"/> <xsd:element ref="NetworkBandwidth" minOccurs="0"/> <xsd:element ref="FileSystem" minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="ExclusiveExecution" type="xsd:boolean" minOccurs="0"/> <xsd:element ref="OperatingSystem" minOccurs="0"/> <xsd:element ref="any" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:NCName"/> </xsd:complexType> </xsd:element>  <xsd:element name="FileSystem"> <xsd:complexType> <xsd:sequence> <xsd:element name="FileSystemType" type="FileSystemTypeEnumeration" minOccurs="0"/> <xsd:element name="Description" type="xsd:string" minOccurs="0"/> <xsd:element name="MountPoint" type="xsd:string"/> <xsd:element ref="DiskSpace" minOccurs="0"/> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:NCName"/> </xsd:complexType> </xsd:element>  <xsd:element name="Network"> <xsd:complexType> <xsd:sequence> <xsd:element name="Description" type="xsd:string" minOccurs="0"/> <xsd:element name="Links" type="xsd:integer" minOccurs="0"/> <xsd:element name="Latency" minOccurs="0"/> <xsd:any namespace="##other"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:NCName"/> </xsd:complexType> </xsd:element>  <xsd:element name="DataStaging"> <xsd:complexType> <xsd:sequence> <xsd:element name="FileName" type="xsd:string"/> <xsd:element name="FilesystemID" type="xsd:NCName" minOccurs="0"/> <xsd:element name="CreationFlag" type="CreationFlagEnumeration"/> <xsd:element name="DeleteOnTermination" type="xsd:boolean" minOccurs="0"/> <xsd:element ref="Source" minOccurs="0"/> <xsd:element ref="Target" minOccurs="0"/> </xsd:sequence> </xsd:complexType> </xsd:element>  <xsd:element name="Source"> <xsd:complexType> <xsd:sequence> <xsd:element ref="User" minOccurs="0"/> <xsd:element name="URL" type="xsd:anyURI"/> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element>  <xsd:element name="Target"> <xsd:complexType> <xsd:sequence> <xsd:element ref="User" minOccurs="0"/> <xsd:element name="URL" type="xsd:anyURI"/> <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element>  <xsd:element name="any"> <xsd:complexType> <xsd:complexContent> <xsd:extension base="xsd:anyType"> <xsd:attribute name="id" type="xsd:NCName"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element>  <xsd:element name="CPUSpeed"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="rangeValue"> <xsd:attribute name="operator" type="operator"/> <xsd:attribute name="units" type="frequencyUnits"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  <xsd:element name="CPUCount"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="rangeValue"> <xsd:attribute name="operator" type="operator"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  <xsd:element name="ResourceCount"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="rangeValue"> <xsd:attribute name="operator" type="operator"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  <xsd:element name="PhysicalMemory"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="rangeValue"> <xsd:attribute name="units" type="storageUnits"/> <xsd:attribute name="operator" type="operator"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  <xsd:element name="VirtualMemory"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="rangeValue"> <xsd:attribute name="operator" type="operator"/> <xsd:attribute name="units" type="storageUnits"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  <xsd:element name="NetworkBandwidth"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="rangeValue"> <xsd:attribute name="units" type="bandwidthUnits"/> <xsd:attribute name="operator" type="operator"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  <xsd:element name="Limit"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="limitValue"> <xsd:attribute name="units" type="limitUnits"/> <xsd:attribute name="name" type="LimitTypeEnumeration"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  <xsd:element name="CPUTime"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="rangeValue"> <xsd:attribute name="operator" type="operator"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  <xsd:element name="ProcessCount"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="rangeValue"> <xsd:attribute name="operator" type="operator"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  <xsd:element name="UserGroup"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="id" type="xsd:NCName"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  <xsd:element name="DiskSpace"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:positiveInteger"> <xsd:attribute name="units" type="storageUnits"/> <xsd:attribute name="operator" type="operator"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element>  </xsd:schema> --BXVAT5kNtrzKuDFl--

1 0