W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2001

Re: Proposal for hierarchical fault codes

From: Martin Gudgin <marting@develop.com>
Date: Wed, 7 Nov 2001 19:53:35 -0000
Message-ID: <00f101c167c5$e46b73b0$977ba8c0@greyarea>
To: "Rich Salz" <rsalz@zolera.com>
Cc: "XML Protocol Discussion" <xml-dist-app@w3.org>

----- Original Message -----
From: "Rich Salz" <rsalz@zolera.com>
To: "Martin Gudgin" <marting@develop.com>
Cc: "XML Protocol Discussion" <xml-dist-app@w3.org>
Sent: Wednesday, November 07, 2001 7:32 PM
Subject: Re: Proposal for hierarchical fault codes


> >    <xs:simpleType name='faultcodeenum'>
>
> How about 'category' or 'faultcategory' for the name?

Oh sure. I wasn't presenting the schema as the 'final' version. I'm certain
there will be plenty of input on what the names should be :-)

>
> I dislike the attribute approach because I want to turn faults into
> local exceptions and vice-versa, in a SOAP RPC environment (perhaps like
> RMI or DCOM's ORPCTHAT parameter).

Err, and why is this more difficult with the attribute based approach. I can
just as easily map an XML attribute to the ORPCTHAT as I can an XML
element...

> I dislike the nested elements
> approach because it seems like a hack, as well as being awkward to
> generate and parse.

How can it be a hack? Infosets are trees, they inherently support nesting.
Nesting implies hierarchy and we're modelling hierarchical fault codes.

In terms of parsing it seems to me that the nested approach is actually
marginally easier in SAX. Taking the attribute version for something with
three QNames you'd have

    ContentHandler::startElement
    ContentHandler::startElement
    ContentHandler::startElement
    ContentHandler::endElement
    ContentHandler::endElement
    ContentHandler::endElement

With the flat approach you'd get

    ContentHandler::startElement
    ContentHandler::characters
    ContentHandler::endElement
    ContentHandler::startElement
    ContentHandler::characters
    ContentHandler::endElement
    ContentHandler::startElement
    ContentHandler::characters
    ContentHandler::endElement

In the DOM the only difference is navigating via firstChild in the nested
approach or nextSibling in the flat approach.

I'd make the same argument for generation...

Gudge

> /r$
> --
> Zolera Systems, Securing web services (XML, SOAP, Signatures,
> Encryption)
> http://www.zolera.com
Received on Wednesday, 7 November 2001 14:54:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:04 GMT