Re: fault/detail

 Hi all, 8-)
 I think it was me who alluded to the possibility of making 
things consistent by removing the requirement that all headers 
and body entries be ns-qualified. 
 I only meant that half-seriously because I'm well aware that we 
would then rely on extension and application authors to judge the 
necessity for namespace-qualification of their elements. I 
believe XML still doesn't mandate namespace qualification. Is it 
in any way official that XML will move to mandate namespace 
qualification?
 Unqualified XML has sense in localized applications where there 
are no concerns about naming conflicts. Why shouldn't it be used 
in localized SOAP exchanges? 8-)

 Anyway, I also prefer mandating ns-qualification, it's just that
the other option is not inherently broken and should not be
dismissed all too easily.

 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



On Tue, 23 Jul 2002, Martin Gudgin wrote:

 > 
 > Noah,
 > 
 > I would agree this issue is only worth fixing if we are delayed for other
 > reasons.
 > 
 > I would note however that I would vote for making children of Detail
 > qualified rather than allowing children of Header and Body to be
 > unqualified.
 > 
 > Gudge
 > 
 > ----- Original Message -----
 > From: <noah_mendelsohn@us.ibm.com>
 > To: "Martin Gudgin" <martin.gudgin@btconnect.com>
 > Cc: "Jacek Kopecky" <jacek@systinet.com>; "Pete Hendry"
 > <peter.hendry@capeclear.com>; <xml-dist-app@w3.org>
 > Sent: Tuesday, July 23, 2002 1:59 AM
 > Subject: Re: fault/detail
 > 
 > 
 > > I think at this stage it's important to take account of the W3C process as
 > > well as the technical niceties.  After well over a year of discussion, the
 > > specification has gone to "last call".  For better or worse, even modest
 > > functional changes or additions (not deletions) are likely to introduce at
 > > least weeks and probably months of process overhead, because W3C rules say
 > > we'd go back to last call with the whole specification.  This is not the
 > > place to debate the merits of the W3C process.  It's got some good and
 > > some bad characteristics, but one of the things we must now do is to set
 > > the bar a bit higher on "nice-to-have" changes.  Anyone who ships
 > > commercial software recognizes this point in the product process, where
 > > stability of the spec becomes important along with its design
 > > characteristics.
 > >
 > > Therefore, I think we need to carefully sort proposed changes into at
 > > least three piles:
 > >
 > > * Worth changing even if it delays the publication of the spec for, say,
 > > 2+ months
 > > * Worth changing only if the spec is delayed for other reasons.
 > > * Wouldn't change it even if there were no delay
 > >
 > > I think the proposal to change the qualification of detail rates no higher
 > > than the middle group, at best.   Getting rid of qualification on headers
 > > and bodies is a very bad idea, IMO, as it undercuts the whole "understand"
 > > mechanism.   We say that each header entry must have a QName that is
 > > described in some specification of which the receiving software is aware
 > > and with which it is conformant.  Making that statement about an
 > > unqualified name seems risky at best.  Thank you.
 > >
 > > ------------------------------------------------------------------
 > > Noah Mendelsohn                              Voice: 1-617-693-4036
 > > IBM Corporation                                Fax: 1-617-693-8676
 > > One Rogers Street
 > > Cambridge, MA 02142
 > > ------------------------------------------------------------------
 > >
 > >
 > >
 >

Received on Tuesday, 23 July 2002 07:20:26 UTC