Resource Management and Accounting Notebook - page 44 of 150

First PagePrevious PageNext PageLast PageTable of ContentsSearch

Date and Author(s)

XML schema - 03/13/02 (mailing list thread)

View Message  
 This is message #21 of a set of 71   
Date: Mon, 18 Mar 2002 16:52:15 -0800  
Author: "Jackson, Scott M"   
Subject: RE: XML schema  
Body: J.P.,  
So, that is exactly where I was a few months ago, I had three grouping  
elements as you did which mapped to yours as follows:  
Mine Yours  
I was thinking of using set too, but I thought it conflicted too much with  
the data structure and didn't sound intuitive when I used it in my code  
(especially for those not familiar with SQL -- also for the same reason, I  
didn't think where would make much sense here to people who are not SQL  
The elimination of these in favor of an operator attribute made alot of  
sense to me but the groupings will work and validate just fine. And yes,  
your select subelements would preserve order just fine.  
I also had  instead of , and   
in the returned data instead of  etc. but XML limits  
you to having that element Request defined in one and only one way -- you  
cannot make the Request element take on an alternate set of behaviors  
depending on its attribute values. I was told my XML should enforce the  
options appropriate for the request type.  
The objection I received there by Narayan and Rusty sunk into my quiet  
ponderings and I have become of the opinion that they were right in this. We  
are not just creating a general standard format for communication, I think  
we are creating a specific interface standard to each component which will  
describe precisely how you ask for any given piece of information from the  
component and how to understand the reply. I think the API must be strong  
enough to be able to say, you can ask for phonenumber and email for a user  
request, but it is incorrect to ask for nodetype in a user request. Armed  
with this information, (that a user query can ask for A, B and C but not D,  
E and F) the other side knows exactly how to generate the request from the  
schema definition alone. Otherwise, our API will simply have be documented  
in some other codification and the schema cannot be used to enforce it. This  
is one of the strengths and redeeming qualities of XML which allows you to  
eliminate all that checking on the application side -- which you certainly  
don't want to have to do -- let the schema do all that for you.  
Now this is easier to facilitate in specific components than in an  
information service component.  
Let's take an a quick aside and look at how to possibly eliminate the  
invalidatability of the component= and datatype= attributes.  
It seems to me that the schema version and type would be selected/specified  
by the namespace support in XML. The way you get the server to use the  
appropriate schema is by passing it through the namespace qualifiers in the  
head element. This, I believe, is the whole purpose and rationale for  
supporting namespaces. I.e. your actual request might look something like:  
(Of course you could have the   
(I used your format this time)  
But what about request pipelining? You could do the following:  
That way your Information service could always look for the same element  
names (Request, select, etc) and all the validating could occur on the  
outside by the XML parser without you needing to worry about the details. I  
still think the select types should be validated, but the beauty of this  
approach is that you do not need to worry about this detail. The person who  
defines the table to your information service basically stores the nd.xsd or  
whatever schema to be used against the data, the parser handles all the  
validating and you can entirely ignore the fact. You can just hand the  
queries directly to the SQL statements since the schema has already proven  
that the fields are correct for the database query.  
-----Original Message-----  
From: JP Navarro []  
Sent: Monday, March 18, 2002 1:19 PM  
To: Scalable Systems Software Resource Management Working Group  
Subject: Re: XML schema  
Hey all, sorry for the lag in response. Watchout of this year's flu!  
So how does the following look for a general Query API?  
Where "component" is who services the query. In this example "qm-1" means  
manager version 1. Datatype is the table or type of data being queried. As  
discussed in the Build and Configure meeting a couple of Friday's ago, one  
the ideas we're floating is that of a general Query API that applies both to  
information service and other components that have query capability. If we  
agree on this general query API, it will be relatively simple for an  
Service to service requests on behalf of other components. The main  
of this idea is that the API command would just be "Query", where  
and "datatype" are metadata attributes of the query.  
"op" is an optional operator which is assumed to be "eq" (equal) when not  
Scott, does this preserve all the appropriate ordering characteristics that  
were concerned about? Each field is an element..  
Regarding the question of validating. I'm not sure how this would get  
but I'd like to _not_ have the parser validate the field names in the  
This could be the update:  
I tried to factor all discussion points into this API, but may have failed.  
"Jackson, Scott M" wrote:  
> JP,  
> To perhaps be more lucid, there are a couple possible approaches to  
> the problem that simple attribute value pairs or simple element value  
> combinations do not allow the specification of the operator to be used to  
> associate the name to the value.  
> The point I want to make is that what we did initially boils down to  
> specifying the operator as a grouping element, i.e.  
> <...  
> <...  
> <...  
> .  
> .  
> .  
> <...  
> as you can see we would have to have a different grouping element for  
> association type we wanted to define. This is very unwieldly.  
> All this can be done away with by being able to specify the operator type  
> an attribute to the element as in my previous posting.  
> A final alternative is to use name mangling which I think we can clearly  
> discard.  
> Scott  
John-Paul Navarro (630) 252-1233  
Mathematics & Computer Science Division  
Argonne National Laboratory  
Argonne, IL 60439  
You are currently subscribed to sss-rm as:  
To unsubscribe send a blank email to $subst('Email.Unsub')  
Quote message in reply   
Because you are a list admin, you are allowed  
to delete messages from the archives.