OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

courtfiling-reqts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Of directories...


Shane,

 

   I agree with the generic explanation, and I did not mean to imply a need for a formal defining of a directory service, if I did, just more definition to what we meant by “directory,” which Jim and You provided.  With profile definitions of WS-1, ebXML, and “sneaker net,” the directories for each profile is evident now that I understand what was meant.

 

Thanks,

 

Rex

 


From: Shane.Durham@lexisnexis.com [mailto:Shane.Durham@lexisnexis.com]
Sent: Monday, April 18, 2005 12:23 PM
To: Rex McElrath
Cc: courtfiling-reqts@lists.oasis-open.org
Subject: Of directories...

 

Shane's view:

 

A 'directory' is similar to DNS.. perhaps with out the 'S'.

 

- A directory represents the known list of MDEs participating in a LegalXML system, and their 'address' for interaction.

 

We have also said this:

- A directory expresses each MDE's type (so that we know what general behavior we might expect from it).

- A directory informs us as to what functions the MDE supports (or, perhaps, what it does not support)

 

However, if given an MDE's address, we could just ask the MDE "What can you do?",  then, we might not even need those last two requirements, or maybe not BOTH of those requirements. (we'll see.)

 

 

And, that's about it, as far as I am concerned.

 

Practically speaking, the directory contents should probably be publish-able somewhere, in some format, for all system participants to  review.  But, not necessarily...

 

(This is where I think we have had some debate...)

 

In my view, each participant should be able to retain and maintain their own data representing a directory.

They do not need to dynamically refer to a centrally-defined directory, of a pre-defined format, on an hourly/daily/weekly basis.

 

The way I see it, each participant may develop and persist their own directory structure in whatever format they desire.

They can learn of other MDE's addresses through any number of practical means ("Dude, what's your IP?")

 

However, if the system were to contain a centrally available directory, in a format that is suitable for all participants, and there exists a system participant/process to assure the directory's accuracy and availability, then it is perfectly reasonable to ask all participants to dynamically refer to that structure before interacting with an MDE.

 

Either of those models are fine by me.

 

Where I feel like we would be going further than necessary, is if we were to attempt to formally define the directory data structure, and formally define interactions with a 'directory server MDE'.

 

1) I think directory contents (i.e. the addresses of MDEs) would have to be specific to whatever profile is being implemented for the system.

A directory for WebServices system, will look different than a CORBA-based system, would be different than a sneaker-net based system.

 

 

2) I believe a centrally-available and accessible directory is only really desirable in those systems where MDEs are joining and leaving the system on a frequent, and generally 'quiet' basis. 

 

We only need the central list to exist so that we might discover the MDEs that are so quietly jumping into the system.

 

Now, that *might* be the case, someday... but, when I put my 'practical cap' on, I recognize, for the foreseeable future, MDEs are not going to enter a system without EVERYONE being very aware, and highly prepared, for the event.  As far as I can see, It will be very unlikely that I'll need to discover MDEs, on a daily/hourly basis, via the central directory.  (for instance:  BearingPoint and LexisNexis would know about each other's participation in the *same* system, almost immediately.  Long before a central directory might ever list us.)

 

And, since it will not be needed for awhile, I say, let's not try to define a 'directory server' at this time.

 

3) As you noted Rex (as did Jim) , the concept of a 'directory' is very similar to UDDI/DNS, etc.

 

I think, for all of the 'profiles' we have kicked around, we will find that there already exists a perfectly suitable way to express a directory, and a perfectly suitable way to publish the directory. 

 

I may have made a call for 'more definition'... but, I really don't want to formally define it with much detail.

I believe our assistance, in terms of development of a standard for 'directory', is not really needed in this area.

 

Perhaps, for specific system profiles, we could offer suggestions/examples, of existing technologies, for a publish-able directory.

That's about as far as I would like to take it.

 

- Shane Durham

LexisNexis FileAndServe

 


This e-mail and any files transmitted with it are intended solely for the use of the entity or individual(s) to whom they are addressed and not for reliance upon by unintended recipients. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail and any files transmitted are strictly prohibited. If you have received this e-mail in error please delete the entire email and immediately notify us by email to the sender or by telephone to the AOC main office number, (404) 656-5171. Thank you.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]