Subject: Changes to the definition of results

From: Roland Hedberg <[email-masked]>
Date: Tue, 22 Aug 2000 17:05:51 +0200

At Fri, 18 Aug 2000 12:42:28 +0900, "Martin J. Duerst" <[email-masked]> wrote:
> At 00/08/17 09:42 -0400, Michael Mealling wrote:
> >5) The current DTD allows you to have a resourcedescriptor with a required
> >serviceref/datasetref and not have a service block. Roland and I think
> >we have a version worked out that looks like this:
> >
> ><!ELEMENT results (
> >( status? | ( service+, (status*, resourcedescriptor*, referral* )* )* )>
> >
> >PLEASE look at this closely! The boundary conditions are hard to see.
>
> Just a quick look shows that there are four '('s, but only three ')'s.
> And in the above, (status*, resourcedescriptor*, referral* )* can (and should)
> be simplified to (status | resourcedescriptor | referral )*.
>
> Please describe exactly what you want (and what you don't want),
> otherwise it's impossible to check this.

Sorry, due to a change in my companies domainname I have been off the
list for a while unknowingly.

My starting point for modifying the definition of 'results' as defined in
draft-ietf-cnrp-04.txt was the following goals :

1) Ability to return only a status message ( nothing new except that it is
status and not error )

2) A resourcedescriptor or referral without a service
description is invalid. For both resourcedescriptor
and referral a serviceref is, according to the DTD, mandatory.
Hence a service has to be defined in the same resultset.

3) The ability to return more than one referral,service,
resourcedescriptor and status message.
( The omission of the '*' in the 04-draft is probably just a
typing error ).

4) Order ?? ( Both good and bad )
I would not mind if, for instance, a service referenced in
a resoucedescriptor preceeded it in the resultset.
It would make it easier to start acting on the result before
everything has arrived.

5) The abillity to 'group' a status message with a set of
service definitions and possible resourcedescriptions and
referrals. Something we dearly wanted while working
with the Tisdag project. That is, this is very usefull when
the CNRP server you are talking to is acting as a gateway/
proxy for a number of underlying services/servers. And
these services/servers might jointly produce any number of
different status/error messages.

6) Nothing prevents a server from running several services
( As for 3, this again is probably just a typing error)

-- Roland

---

From: "Martin J. Duerst" <[email-masked]>
Date: Wed, 23 Aug 2000 13:55:41 +0900

>1) Ability to return only a status message ( nothing new except that it is

That works. The current syntax also allows to return nothing at all,
is that indeed intended or not? Also, it doesn't allow to return
both a status and something else, is that intended or not?

>2) A resourcedescriptor or referral

or status

>without a service

Using only ordering for grouping is in general a bad idea.
It would be better to introduce some kind of 'group' element
if you really want this feature.

>( As for 3, this again is probably just a typing error)

Regards,   Martin.