RE: Proposal: abstract faults (amended)


many thanks - that makes a lot more sense!
i'll repost with the amended pseudo-schema.


-----Original Message-----
From: Roberto.Chinnici@Sun.COM [mailto:Roberto.Chinnici@Sun.COM]
Sent: 20 January 2004 03:18
To: Downey,PS,Paul,XSJ67A C
Subject: Re: Proposal: abstract faults (amended)


I should have sent out email about the amendment I proposed, sorry.

Indeed, I think that @messageReference should be defined on 
and interface/operation/outfault rather than on interface/fault.

The rationale for that, as you correctly stated, is that the value
of this attribute depends on the MEP in use by the operation that
uses the fault.

But @message definitely belongs on interface/fault, because its
value won't vary across operations, and in particular it does
not depend on any MEP.

Also, I have to say that after thinking about it a bit more, I'm not
so sure that the interface/fault/@name attribute should be of type
xs:QName. I think your original (pre-amendments, that is) proposal
got it right in using xs:NCName. I'd hate to have to explain to people
why the name of an operation is an NCName while the name of a fault is
a QName given that they are defined in the same scope (an interface).

On the other hand, Amy was right in pointing out that *references* to
a fault should use xs:QName.

So my proposal is to revert interface/fault/@name back to a xs:NCName
all while keeping references to faults as xs:QName(s). This is entirely
consistent with the use of xs:QName for the binding/operation/@name attribute
(a reference to an operation).

Here's the updated pseudo-schema:


     <fault name="ncname"
        <documentation />?

       <(in|out)fault name="qname"

       <(in|out)fault name="qname">



Roberto Chinnici
Java Web Services
Sun Microsystems, Inc.

Received on Tuesday, 20 January 2004 04:59:09 UTC