W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

Who Faulted (was RE: Proposed rewrite of Part 1, section 2 (long) )

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Wed, 30 Jan 2002 22:06:52 -0000
Message-ID: <5E13A1874524D411A876006008CD059F192917@0-mail-1.hpl.hp.com>
To: "'Jacek Kopecky'" <jacek@systinet.com>
Cc: xml-dist-app@w3.org

Hi Jacek,

Sure... it wasn't a heavy suggestion, but any such extension might benefit
from a common mechanism to denote what node faulted, rather than inventing
its own means of dropping the information in the fault detail. Doing it an
common way also means that the information is accessible to things that
don't understand the extension. It may also be the case that there is such a
mechanism... I haven't looked at the faulting parts of the spec recently.

Any not really pushing, was just wondering generally whether it was more
useful to know what node or what role faulted and in some cases you'd
probably want one, the other or both (although we have now completely
avoided identifying nodes (I think) by talking solely about roles).



> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@systinet.com]
> Sent: 30 January 2002 21:28
> To: Williams, Stuart
> Cc: xml-dist-app@w3.org
> Subject: RE: Proposed rewrite of Part 1, section 2 (long)
>  Stuart,
>  that's certainly right, but then any extension that assumes its 
> headers will be targeted at "../next", should handle the failures 
> in a way, for example by employing the fault detail element.
>  Also, knowing that "urn:foo" faulted when nothing was targeted 
> at it might not be too useful either. 8-)
>  Best regards,
>                    Jacek Kopecky
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
> On Wed, 30 Jan 2002, Williams, Stuart wrote:
>  > Hi Jacek,
>  > 
>  > Knowing that '../next' faulted might not be too useful!
>  > 
>  > Stuart
>  > 
Received on Wednesday, 30 January 2002 17:06:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:45 UTC