Re: proposal to have sequential / grouped messages in soap output

Hi folks :)

> > * checkedby
> I think this is information that the client should already know, but
> adding a URI that points to the checker would be harmless except for
> the response size increase. (It should probably be called checked-by
> for consistency with the other hyphenated names.)

Agree. I even wonder how "useful" could this information be for
an application since it's that application that made the query.
This isn't supposed to be used by the final user.

> > As far as I can tell most implementations just parse the XML of the
> > SOAP output. I think one of them does build upon a SOAP library and
> > thus expects the format to be in a SOAP envelope.
> >
> > One option I am pondering about is to leave the SOAP output as it
> > is (that is, with its oddly grouped messages) and revive an XML
> > output.
> Makes sense.

Yes, please! :)
I'm about to release an app I made that uses this soap format.
Not that I'm in love with it, but I'd be happy to adopt a new
xml format after my release ;-)

> I guess every message element (<info>, <error>, <non-document-error>)
> could be given an attribute called e.g. message-id that gives an
> implementation-specific message identifier. (It should not be called
> id, since implying IDness would be bad as there can be multiple
> instances of a given message.) It could further be stipulated that
> since message-id is implementation-specific, checked-by SHOULD be
> used (on the root or on the message) when message-id is used. If a
> client does not recognize the checked-by value and, thus, is unable
> to use implementation-specific semantics, it could still compare the
> message-id values for strict string equality to discover which
> messages are instances of the "same" message. Hence, equivalence
> classes could be established without knowing the semantics of the
> equivalence classes.

I think -correct me if I'm wrong- that Olivier meant by "id" a single
"code" associated with a message. That's a concise way to identify
a message, not in the current validation response context but in the validator
"database" of messages. Could be and will be, IMHO, useful for l10n
and for per-application custom messages.
What could annoy a little bit is that name "id". Maybe we could call
this "message-dbid", just to say that it's an ID but in the messages
DB context.

Innovate Humanum Est

Received on Wednesday, 31 October 2007 19:59:45 UTC