Resource Management and Accounting Notebook - page 43 of 150

EditDeleteAnnotateNotarize
First PagePrevious PageNext PageLast PageTable of ContentsSearch

Date and Author(s)

XML Schema thread

sss-rm 
View Message 
   
 
 
 This is message #26 of a set of 71  
   
  
Date: Wed, 13 Mar 2002 11:45:51 -0700 (MST) 
  
Author: Dave Jackson  
  
Subject: RE: Fwd: RE: XML schema 
  
Body: Scott, 
 
Let me clarify. I agree that the return data should be an object, not 
an attribute. (I apologize that I did not notice the 'jobid=X' in JP's 
example. What I was looking at was the 'meta' attributes like status 
code, human readable message 'about' the command, etc. Those are in fact 
attributes of the message and not contents of it. The data specifying the 
request and the data responding to the request are contents and should be 
sub-elements. 
 
Dave 
 
On Wed, 13 Mar 2002, Jackson, Scott M wrote: 
 
> JP & Dave, 
> 
> I started with this approach and was forced to abandon it. This approach 
> will only work if you know beforehand that all of your options will always 
> be simple non-repeating unstructured name-value pairs. If even one of your 
> options do not fit into this paradigm then you are forced to either do some 
> one way and some another (which I dislike because it is inconsistent) or go 
> with the subelement approach. I don;t think there is a difference in 
> efficiency, and handling subelements is at least as easy as handling 
> attributes. 
> 
> In my world, (and I think it will be so in your world sooner or later) I 
> have the need to specify multiple options with the same name but different 
> attributes. This cannot be done in a single attribute name value list. 
> Furthermore, alot of the comparisons are not simply equality, some 
> relationships are "less than or equal", some are assignment, some are 
> matching, some are flags only (don't have values), etc. This cannot be 
> codied in AVP's without name mangling or resulting in unvalidatable values. 
> Not surprisingly, in my browsing of many implementations, I have found the 
> subelement approach to be the norm. 
> 
> Scott 
> 
> -----Original Message----- 
> From: Dave Jackson [mailto:jacksond@supercluster.org] 
> Sent: Tuesday, March 12, 2002 7:23 PM 
> To: Scalable Systems Software Resource Management Working Group 
> Subject: Re: Fwd: RE: XML schema 
> 
> 
> JP, 
> 
> I think I would also prefer this approach. It much more 'to the point'. 
> 
> Dave 
> 
> On Tue, 12 Mar 2002, JP Navarro wrote: 
> 
> > Brett, 
> > 
> > A different way you could format the same response is: 
> > 
> >  
> >  > jobID='2342.whatever' /> 
> >  
> > 
> > I picked this format for the Information Service because it's more 
> > compact. 
> > 
> > JP 
> > 
> > Brett Bode wrote: 
> > > 
> > > > That is basically the sort of layout that we have been working on. I 
> > > > think we shortened your QueueManagerRequests to QMRequests. One 
> > > > thing I hadn't been thinking of is the  elements. What are 
> > > > their purpose? on the response I was thinking of: 
> > > 
> > > > 
> > > >  
> > > 
> > > >  
> > > 
> > > > true 
> > > 
> > > > 000 
> > > 
> > > > Job accepted 
> > > 
> > > > 2342.whatever 
> > > 
> > > >  
> > > 
> > > >  
> > > 
> > > > 
> > > > I guess the  element would provide a "container" for more 
> > > > arbitrary fields, but I guess I am not sure that they are needed. 
> > > 
> > > > 
> > > > On the Job description I am open to suggestions. We have been 
> > > > tossing out ideas here about whether the job description should be 
> > > > fairly flat or heirarchical. The main argument for a flat structure 
> > > > seems to be related to the arbitrary fields that can be in the 
> > > > request. So the request might look like: 
> > > 
> > > > 
> > > >  
> > > 
> > > >  
> > > 
> > > > ACTIVE 
> > > 
> > > >  
> > > 
> > > > Username 
> > > 
> > > > Node Count 
> > > 
> > > > .... 
> > > 
> > > >  
> > > 
> > > >  
> > > 
> > > >  
> > > 
> > > > 
> > > > The jobID field would be allowed to specify a specific ID or a 
> > > > wildcard (like ALL, or ACTIVE). The response might be: 
> > > 
> > > > 
> > > >  
> > > 
> > > >  
> > > 
> > > > true 
> > > 
> > > > 000 
> > > 
> > > > 5 Jobs found 
> > > 
> > > > 5 
> > > 
> > > >  
> > > 
> > > >  
> > > 
> > > > 23 
> > > 
> > > > bob 
> > > 
> > > > 4 
> > > 
> > > > ... 
> > > 
> > > >  
> > > 
> > > >  
> > > 
> > > > 24 
> > > 
> > > > bob 
> > > 
> > > > 8 
> > > 
> > > > ... 
> > > 
> > > >  
> > > 
> > > > .... 
> > > 
> > > >  
> > > 
> > > >  
> > > 
> > > >  
> > > 
> > > > 
> > > > So I think the structure is similar to what you proposed. Is that 
> > > > the sort of thing you and Dave had in mind with respect to the query 
> > > > syntax? 
> > > 
> > > > 
> > > > Brett 
> > > 
> > > > 
> > > > At 5:21 PM -0800 3/11/02, Jackson, Scott M wrote: 
> > > > 
> > > >> Well, 
> > > >> 
> > > >> I have been working hard to try to come up with a format that will 
> > > >> work 
> > > >> generally across the RMWG components for request and response 
> > > >> syntaxes. 
> > > >> 
> > > >> I am sorry I have not gotten you anything yet. I have been making 
> > > >> some last 
> > > >> minute modifications as a result of testing my prototype in real 
> > > >> use. So 
> > > >> basically I would like to propose something like: 
> > > >> 
> > > >> Submitting a job: 
> > > >> 
> > > >>  
> > > >>  
> > > >>  
> > > >>  
> > > >> .... 
> > > >>  
> > > >>  
> > > >>  
> > > >>  
> > > >> 
> > > >>  
> > > >>  
> > > >> true 
> > > >> 000 
> > > >>  
> > > >> fr12n05.12345.0 
> > > >>  
> > > >>  
> > > >>  
> > > >> 
> > > >> 
> > > >> Now, I was assuming you and Dave would be interested in handling 
> > > >> the 
> > > >> business of what the makeup of the  object looked like. I 
> > > >> assume it 
> > > >> would have to have some internal structure of its own such as: 
> > > >> 
> > > >>  
> > > >>  
> > > >>  
> > > >> ... 
> > > >> ... 
> > > >>  
> > > >>  
> > > >> ... 
> > > >>  
> > > >>  
> > > >>  
> > > >>  
> > > >> ... 
> > > >> ... 
> > > >>  
> > > >>  
> > > >> ... 
> > > >> ... 
> > > >>  
> > > >> ... 
> > > >>  
> > > >> ... 
> > > >>  
> > > >> 
> > > >> I just intend to treat it (job data) as some tree-like structure 
> > > >> which we 
> > > >> may want to define in a separate schema (separate from the queue 
> > > >> manager 
> > > >> schema) so different component schemas can "import" and use the 
> > > >> same job 
> > > >> schema definition (i.e. scheduler, queue manager, job manager can 
> > > >> all use 
> > > >> the same structure though they may not all use all parts of it). 
> > > >> 
> > > >> I was going to go into a description of why I am recommending a 
> > > >> request/response format that I am near the top, but I am running 
> > > >> off to a 
> > > >> class. So I will try to throw something together tomorrow morning 
> > > >> or just be 
> > > > 
> > > >> prepared to discuss it at the call. 
> > > > 
> > > >> 
> > > >> Take care and thanks for your good work! 
> > > >> 
> > > >> Scott 
> > > >> 
> > > >> -----Original Message----- 
> > > >> From: Brett Bode [mailto:brett@scl.ameslab.gov] 
> > > >> Sent: Monday, March 11, 2002 2:21 PM 
> > > >> To: Jackson, Scott M 
> > > >> Subject: XML schema 
> > > >> 
> > > >> 
> > > >> Hi Scott, 
> > > >> I was wondering if you could update me on what portion of the 
> > > >> overall XML schema that you are working on. 
> > > >> 
> > > >> Thanks, 
> > > >> 
> > > >> Brett 
> > > >> -- 
> > > >> 
> > > >> ____________________________________________ 
> > > >> Dr. Brett Bode 
> > > >> 329 Wilhelm Hall 
> > > >> Ames Laboratory 
> > > >> Iowa State University 
> > > >> Ames, IA 50011 (515) 294-9192 
> > > >> brett@scl.ameslab.gov FAX: (515) 294-4491 
> > > >> ____________________________________________ 
> > > > 
> > > > 
> > > > 
> > > > -- 
> > > 
> > > > 
> > > 
> > > > 
> > > > ____________________________________________ 
> > > > Dr. Brett Bode 
> > > > 329 Wilhelm Hall 
> > > > Ames Laboratory 
> > > > Iowa State University 
> > > > Ames, IA 50011 (515) 294-9192 
> > > > brett@scl.ameslab.gov FAX: (515) 294-4491 
> > > > ____________________________________________ 
> > > 
> > > -- 
> > > 
> > > ____________________________________________ 
> > > Dr. Brett Bode 
> > > 329 Wilhelm Hall 
> > > Ames Laboratory 
> > > Iowa State University 
> > > Ames, IA 50011 (515) 294-9192 
> > > brett@scl.ameslab.gov FAX: (515) 294-4491 
> > > ____________________________________________ 
> > 
> > 
> 
> 
 
--  
------------------------------ 
Supercluster Development Group 
Scheduling and Resource Management of Clusters and Grids 
http://supercluster.org 
  
                            
   
Quote message in reply  
 
   
 
 
-------------------------------------------------------------------------------- 
Because you are a list admin, you are allowed 
to delete messages from the archives.