From: P.J. S. <pe...@mi...> - 2002-12-20 00:30:08
|
All, I'm responding in BOLD and hopefully that'll live through your email = client. Peej Please take the time to answer the following questions: 1.. Would you be free to participate in a teleconference on = Wednesday, 15 January (same date for everyone) at 5am in Tsukuba, 7am in = Canberra, 9am in Christchurch, 12 midday in San Francisco, 2pm in = Kansas, 6pm in Sao Paulo, 9pm in Paris/Berlin/Copenhagen, lasting for = one or two hours? This is the best time I can find to accommodate = everyone that I believe will actually be doing work on DiGIR development = in the next year (particularly Australia, New Zealand, the US, Brazil = and Berlin) although I realise that it is very unfriendly for the Far = East.=20 yes 1.. Would you be prepared and able to travel to a 2 or 3 day meeting = to work on the DiGIR protocol and associated software? I think that = California might be a sensible venue if most of us were to attend, but = alternative suggestions are welcome.=20 yes, assuming funds are available 1.. Do you expect to use the DiGIR protocol to exchange data within = 2003? If so,=20 1.. What schemas do you expect to use to model requests and = results?=20 2.. Identify any critical dates for your projects.=20 yes, at least as part of the MaNIS project. i will have to defer to = John W. as far as specifics but i believe his goal is to exhange data = based on a mammal specific version of darwin core v. 2. as far as = dates, i must completely defer to John W...who's hunting rodents in = argentina still. 1.. Do you expect to develop any DiGIR software in 2003? If so,=20 1.. What components will you be developing (Provider, Portal = (federation), Client)?=20 as far as i know, the portal side is all i am slated for for now. = i've been developing a generic portal that is currently configured = (graphically and schema wise) for MaNIS but there is no reason it could = not be otherwise adapted. i'm not sure i understand what you mean by = client...i'm assuming you have singled out Portal to mean the engine = without the presentation layer and if so, then client =3D presentation = layer...in which case i also work on that. 1.. Will you be developing on the SourceForge code base or = separately=20 assuming i'm still working on what is a reference implementation, i = will continue to work on the SF code base. i would like to point out = though, that there is no reason that there cannot be multiple codebases = on SF so we should keep that in mind when asking such questions. 1.. Will your components be available for others to use?=20 yep 4.. Can you please comment on a proposal from the BioCASE team to = make certain changes to the DiGIR protocol schema (see = http://www.biocase.org/temp/protocol/BioCASEproposal.htm). this is nice to see 4.. The changes proposed are:=20 1.. Add a Capabilities request to query schemas supported by a = Provider.=20 well, i am not sure i agree with this. in essence it appears to be a = way to ask for certain bits of the metadata. if it is the case that a = provider can support certain schemas for requests and certain schemas = for responses, then those schemas should already be part of the overall = metadata. i do not see why one needs an individual call to get a subset = of the metadata. it seems to me the portal should make a metadata call = upon startup (and periodically for refreshing probably) and store that = data as it needs it...including indexing bases on schemas supported. i = don't think i support the notion of having a seperate call for a subset = of what seems like metadata in such a manner. of course, i haven't = really seen arguments for needing to do so. 1.. Replace substitution groups with XPath expressions.=20 this is somewhat of a misleading sentence because one is not the = replacement for the other straightup. however, the idea here is that we = get rid of the notion of abstract datatypes that are used to help type = certain things in the filter structure for validation via substitution = groups used in a "bound" federation schema. and instead, we use xpath = expressions to represent the concepts in the filter. part of the = disadvantage of giving up the original method is that validation is no = longer possible at an xml parser level. the validation i speak of comes = in a number of forms. for one, we were able to distinguish between = searchable versus returnable concepts and automatically disallow a = filter trying to query on something not queriable. of course, if you = split the schema's into two that issue is no longer one. the second = thing the original design allowed for was for automatic validation of = types within your filter structure. for example, if one said = <equals><month>18</month></equals> the xml parser/validator could = immediately say this was invalid because 18 is out of range. the = advantage of this is that at the earliest time possible, in the portal = (perhaps even in the presentation layer) an error could be given to the = user before sending out what is an invalid request to X number of = providers. under the new design <equals = path=3D"/blah/blah/blah/month">18</equals> would be fine because you've = lost the notion of data typing within xml and xml schema. so by = bringing in part of another technology, xpath and eliminating the use of = part of xml/xmlschema...you are losing something and gaining something = but using neither technology for some of the things they are quite good = at. basically it makes me feel like we're missing the boat on both = technologies. 1.. Add a Transformation element to identify an XSL style sheet = which the Provider should use to transform the output before returning = it.=20 i have no fundamental problem with this notion. its kind of a nice = idea. however, the question leaves out the changes to the protocol = referring to requestFormat and responseFormat. my issues around this = would probably just bounce around the notion of where this stuff would = validly belong in the document and what it should be called. for = example...it was already partly supported under the existing <structure> = element...etc... 1.. Replace the existing logical operators with AND, OR and NOT.=20 my only questions around this would relate to what are and are not the = valid combinations and would relate to how an interface would present = them, considering sometimes you would have on operator and sometimes you = would have two. of course, this has an implication on the schema as = well. 5.. Please suggest any agenda points you would like to have covered = in a teleconference.=20 additions and notes: * why above you noted to again talk about soap, xmlrpc, etc? we will = never get anywhere if we continue to ask the same question when i = thought it had already been decided and understood (not to mention = built) to do XML over HTTP. * the notion of registry is OUTSIDE of digir protocol discussion. it = is an implementation question and choice. * the notion of custom responses and the current ability to pick and = choose your result. is this required? desired? still possible when = one considers an ABCD schema? * timing implications and their impacts on existing projects |