-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well, I think I was trying to say something along those lines, but
you stated it much more clearly than I did. In addition, I completely
agree with you in regard to both the importance of RNS/Directory
services to OGSA-Naming and the fact that GFS is a more appropriate
forum for the refactoring work to be completed. (I assume you mean
"OGSA-Naming" below instead of "WS-Naming")
I think it's extremely important that this work not just end up being
done by Manuel and Mark for lack of an agreed-upon forum and process;
not that they aren't perfectly capable, but we do have GGF and five
thousand working groups around for a reason... As I said previously,
if there was a final decision made at the F2F on which forum to use
to do this, I missed it. My own suggestion is that we stick with the
original plan, i.e. finish the development process in GFS, which of
course will be more than willing to accept participation from
interested parties, then hand it off to OGSA-Naming.
How do we reach "official" consensus on this? Or did we do so
already, and I just didn't hear it over the phone?
On Apr 9, 2006, at 8:16 AM, Mark Morgan wrote:
> Chris,
>
> Thanks for your input and assessment of the situation. I believe
> you are
> correct but I did want to make one small clarification (and please
> forgive
> me if I am re-stating something already said in this email -- it's
> early and
> I'm still jet-lagged). It isn't that I think that hierarchical naming
> doesn't belong in WS-Naming. In fact, it's VERY important there.
> However,
> I don't think that re-factoring RNS as an activity belongs in WS-
> Naming.
> WS-Naming should help with this, but I definitely believe that the
> re-factoring effort needs to take place in GFS where the goals and
> beliefs
> of the original authors can best find voice. If this makes any sense!
>
> -Mark
>
>> -----Original Message-----
>> From: Christopher Jordan [mailto:ctjordan@sdsc.edu]
>> Sent: Sunday, April 09, 2006 3:57 AM
>> To: Dave Berry
>> Cc: Ian Foster; gfs-wg(a)ggf.org; Andrew Grimshaw; Hiro
>> Kishimoto; Mark Morgan; Gregory Newby;
>> ogsa-naming-wg(a)ggf.org; ogsa-wg(a)ggf.org
>> Subject: RE: GGF/OGSA standards for hierarchical namespaces
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> (I don't seem to have any record of minutes having been taken
>> or sent out for this session - if I'm wrong or just missed an
>> e-mail in the endless shuffle of my inbox, feel free to
>> correct me, but this document may be taken as a poor-man's
>> minutes, rambling, incoherent, and just plain wrong though it
>> may be in parts - I was calling in and so wasn't always able
>> to catch all of the discussion.)
>>
>> First, I'd like to again thank all the participants in the
>> e-mail and the F2F discussions for helping us to move this forward.
>>
>> Regarding the F2F Naming session, I think the
>> RNS/WS-Directory portion was a very productive discussion,
>> and it certainly seemed to me that there is general agreement
>> on the need for a refactored or decomposed version of RNS, as
>> well as agreement on the general components that will be
>> required. I will refer to the portion of the re-factored RNS
>> that provides the POSIX directory-like functionality
>> RNS-Directory, for lack of a better term at this point. In
>> fact, the sense I got was that not only is it generally
>> agreed that this type of thing is needed, but that it is
>> needed as soon as possible; I certainly feel this way, since
>> much of the work of the GFS-WG should ideally consist of the
>> definition of a "profile" for GFS usage of RNS- Directory.
>>
>> Mark Morgan made it abundantly clear that WS-Directory is not
>> currently being offered as a proposed GGF standard document,
>> but is merely intended to provide a somewhat simpler, and in
>> fact quite minimal, example of a hierarchically structured
>> set of human-readable names which are associated with XML
>> documents containing at least an EPR and, as of the most
>> recent version, arbitrary XML, as the entry document
>> definition includes an "{xsd:any} *" component. I, for one,
>> feel that WS-Directory will be a a valuable reference point
>> in the development of the directory service component of RNS
>> 2.0, or whatever it ends up being called.
>>
>> Initial action items coming out of the discussion were that
>> Mark Morgan and Manuel Pereira were to do some communication
>> to try and get synchronized on at least some initial ideas
>> about what might need to come out of RNS and how it might
>> need to be changed in order to get to this magical future
>> invention I call RNS-Directory. I've offered to help in
>> whatever capacity I can, including arranging for mailing
>> lists and conference calls if necessary, in addition to
>> offering my opinions, which by this point is probably assumed ;-).
>>
>> My personal feeling was that the most difficult issue to
>> resolve was the question of where the re-factoring effort
>> should live and how it should proceed; , but it seemed to be
>> generally agreed that GFS-WG is too far down the GGF
>> hierarchy to be responsible for something that, as someone
>> put it most appropriately (sorry for not recognizing your
>> voice), needs the level of visibility associated with being at the
>> OGSA-* level. At the same time, Mark Morgan suggested that
>> perhaps OGSA-Naming wasn't necessarily a perfect fit for this
>> effort, as there isn't quite the right overlap with the
>> efforts and individuals currently in OGSA-Naming. The last
>> suggestion I heard clearly in toto was that it should be
>> "officially" part of OGSA-Naming, but that it may need
>> separate conference calls, GGF sessions, and other devices to
>> maintain at least some separation from the mainstream
>> OGSA-Naming work. Manuel explained to me, as a relative
>> newcomer, the original agreement that the GFS-WG would be
>> responsible for development of RNS, and that OGSA-Naming
>> would then take over maintenance of it once it had become a
>> GFD, and something like this still seems like a good idea,
>> as long as we can maintain the required level of visibility.
>>
>> I'd appreciate it if someone who was there could let us all
>> know what, if any, final decisions were made regarding how
>> this process will proceed.
>>
>> I haven't had a chance to look at WS-Enumeration, but it's on
>> my reading list - at the least, it should be useful in
>> thinking about how to integrate the directory work with
>> separate and more generally applicable iteration or
>> enumeration standards.
>>
>> Thanks,
>>
>> On Apr 5, 2006, at 12:53 PM, Dave Berry wrote:
>>
>>> Hi Chris,
>>>
>>> Thanks for this note. I hope the F2F discussion is productive.
>>>
>>> I will repeat my suggestion that the naming team should look at
>>> WS-Enumeration to see if it, or an extension thereof, satisfies the
>>> requirements for an iteration interface. I have no idea whether it
>>> does meet those requirements but we should take a look. This is
>>> especially true given the MS/IBM/HP/Intel WS white paper, which has
>>> WS- Enumeration in at the bottom layer.
>>>
>>> Another question I've had raised to me is whether we can
>> use WSRF/WSRT
>>> to handle the properties associated with entries in the
>> directory. I
>>> personally don't see how this would work, but given the
>> context we're
>>> working in it would be helpful to establish what
>> relationship exists,
>>> if any.
>>>
>>> Best wishes,
>>>
>>> Dave.
>>>
>>
>> - ----------------------------------------------------
>> Chris Jordan
>> HPC Systems Engineer
>> High End Computing Systems Group
>> San Diego Supercomputer Center
>> ctjordan(a)sdsc.edu
>> 858.534.8347
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.1 (Darwin)
>>
>> iD8DBQFEOL5nPCVtcXn6kg8RAvUhAJoD9nu2O8c2sxUzDbFDkD0lrFziRQCeIqcX
>> 8HpYq17rM4OSxlCXLV/VNFQ=
>> =uKze
>> -----END PGP SIGNATURE-----
>>
>
- ----------------------------------------------------
Chris Jordan
HPC Systems Engineer
High End Computing Systems Group
San Diego Supercomputer Center
ctjordan(a)sdsc.edu
858.534.8347
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEPQuUPCVtcXn6kg8RAowjAJ4nFZOnEMnrOY1pzbNpnKhGWsW+owCgiscr
AzFY50zRmN3nexUNt+Rlfwo=
=qBFr
-----END PGP SIGNATURE-----
