FYI, I have put the master slide on NAREGI adoption of GGF and other standards. It does not merely focus on information systems, but rather on the 
entire software stack, but should be useful for discussions for this thread as well as others. A greatly stripped down version of this document will 
be presented as a keynote co-presented with Dave Snelling on Thursday.

Quite in agreement with your last comment, Laura. It should serve as a basis of discussion.

Regarding OGSA-DAI and query language comparison, that is another valid activity. Having said that I believe query into CIM DB using SQL is quite 
commonplace, and OGSA-DAI merely serves as a web service that provides remote SQL capability. The difference in the query style rather stems from how 
the underlying schema is stored and represented, as fairly rigourous CIM schema in a DB, or say in a mo more "loose" fashion using LDAP. 

Both are used in the industry today in a rather interoperable fashion depending on its usage. Even within NAREGI personal account information is 
stored in LDAP provided by NAREGI CA, whereas the accounting information is stored in the CIM DB in the information service for the beta 1.

Regarding Charlie's questions and Satoshi's comments on MDS4 -- the MDS4 services will accept and manage any XML-formatted data and does not require 
any particular schema.  A typical MDS4 index out of the box today includes GLUE schema information reported by GRAM along with data in other schemas 
reported by other services.  It's not clear to me that all this data would necessarily fit into the CIM schema (for example, the RFT data includes 
some specifics about the number of transfers completed, the number of bytes transferred, etc.).  MDS4 has some issues with performance on large 
databases. but improving scalability is a high priority for the MDS group.

I think it's important that whatever solution the interop group comes up with allows for management of data about many types of resources and services
, and that it be flexible enough to make it easy to add information about new types of resources and services.

Putting a preliminary email discussion into tracker w/ Satoshi's permission-

On Tue, 24 Jan 2006 11:29:18 -0600
Catlett-> 
This paper does a good job giving an overview, but I still not entirely clear on the steps or timing toward low-hanging fruit next steps for 
production Grids.  

Matsuoka->
Agreed. The paper was meant as more of a position statement from NAREGI rather than a impartial status quo document. Nevertheless I felt it was a good
 starters for getting comments. We do need an alternative document structure to gather status quo of each major infrastructure. I will work on a 
revised structure over the next few days.

Catlett-> 
The paper mentions that NAREGI will do some work in 2006 but it is not clear when in 2006 or what will be the status of the work for production use.

Matsuoka->
The delivery is May 2006. It will be in beta in terms of being "product level" by enterprise-class standards (which may be interpreted as being 
production level in terms of most open source software).

Catlett-> 
I like the approach outlined, but given it has been almost 4 years since the GLUE work started, it would not be unreasonable to think that it will 
take a while for the CIM/GLUE work to mature. In the meantime, is there not a subset of GLUE that multiple grids  could support in early 2006, given 
so many Grids report that they use GLUE?

Matsuoka->
Here are the pros and cons, sprinkled by a little bit of fear scenarios:

=======
Pros for maintaining GLUE:

- That GLUE embodies 4 years of experiences and knowledge that has been accumulated for grid operations, and might contain info pertinent to grid not 
otherwise described in other resource schemas (like CIM).

- It is in use by major grid infrastructures such as OSG and LCG.

- There are production-level grid information systems such as R-GMA that spits out GLUE-compliant information.

- Others?

======

- The entire server and services industry, incl. Web Services, IBM,
Microsoft, etc., are set on CIM as the interoperable standard. The
Windows registry is based on CIM. Thus, one fear scenario is that the grid community will be alienated from the larger IT industry.

- GLUE does not have a developed schema for integration of lower-level, detailed resource information that may be necessary for other purposes  (such 
as remote maintenance) which are present in CIM.

- There is a lack of industry-level tools for information manipulation.
This is akin to the OGSI vs. pure Web Services model (which lead to OGSI to WSRF changeover "event").

- Others?

=======

Matsuoka->
(Below should be recorded in a more impartial, project-centric view portion of the document).

Now, personally speaking, I believe that much of the GLUE vs. CIM feature comparison was technically valuable but somewhat lacked substance, because 
of the unavailability of "grid-enabled" information and monitoring services, whereas GLUE had stuff in operation. However, this may be changing 
because such implementations of systems will be appearing on the CIM side (NAREGI for one, but probably more from the industry side if they are really
 serious). 

So, if the GLUE folks think that the industry at large will move towards
GLUE, it is not going to happen, ever, since there is so much commitment into CIM in the industry, esp. DMTF. I find this synonymous to the situation 
where HEPNET ran its private protocols (DECNET), claimed that they need to sustain that because they were too busy, until they finally "succumbed" to 
TCP/IP.

So, I believe the most profitable course of action is really to 

(1) see how the GLUE knowledge can be transferred to CIM, and
(2) build systems where they could be interoperable in the interim

That is to say, we really need to separate the issue of schema consolidation versus the actual systems. (2) is more easily achievable than (1), since 
if the schema could be preserved for GLUE, then the clients may really not see the difference. In that regard, we concluded that, NAREGI could 
accommodate GLUE in its information services as a proprietary extension to CIM.


Catlett-> 
Or is there a simple way to use the GT4 information services (i.e. is there a simple schema or are these really just blank slates into which you pour 
things like your implementation of GLUE or CIM)?

Matsuoka->
My observation is that GT4 is fairly schema-less, and its information service is more fine-grained, i.e., good for keeping smaller amounts of data but
 not equipped to handle large information schema. In that regard say NAREGI-IS and GT4 information are complimentary, and the latter can be a 
information provider for the former.