- From: Karim A. <directeur@gmail.com>
- Date: Wed, 31 Oct 2007 20:53:11 +0100
- To: "Henri Sivonen" <hsivonen@iki.fi>
- Cc: "olivier Thereaux" <ot@w3.org>, "W3C Validator Community" <www-validator@w3.org>, "Chris. Parrish" <chris.forummail@swankinnovations.com>, "Brett Bieber" <brett.bieber@gmail.com>, "Struan Donald" <struandonald@gmail.com>
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. Karim -- http://akoncept.com Innovate Humanum Est
Received on Wednesday, 31 October 2007 19:59:45 UTC