Resource Management and Accounting Notebook - page 44 of 150
XML schema - 03/13/02 (mailing list thread)
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
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:
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
and grouping elements in the
above, I just am showing how they can be avoided if desired. I use the
grouping element of to distinguish from items that might be
sent in along with a request such as when submitting a job you might send in
a job object as data.)
I recognize that your component will want to know to interpret certain
keywords like Request the same and it would be a little harder to have to
look for "*Request", so a possibility is that each request type has its own
schema (namespace). In that case, each request COULD be called .
They would be differentiated by the namespace. Then we would have:
(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.
From: JP Navarro [mailto:firstname.lastname@example.org]
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
and elements. Those are too dynamic (i.e. in the case of the
Service I don't want to generate a schema used for validating every
table/datatype). Perhaps based on that consideration a better API would be:
This could be the update:
I tried to factor all discussion points into this API, but may have failed.
"Jackson, Scott M" wrote:
> 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
John-Paul Navarro (630) 252-1233
Mathematics & Computer Science Division
Argonne National Laboratory email@example.com
Argonne, IL 60439 http://www.mcs.anl.gov/~navarro
You are currently subscribed to sss-rm as: firstname.lastname@example.org
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.