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

Re: fault/detail

From: Jacek Kopecky <jacek@systinet.com>
Date: Fri, 19 Jul 2002 10:05:41 +0200 (CEST)
To: xml-dist-app@w3.org
Message-ID: <Pine.LNX.4.44.0207191005320.12156-100000@mail.idoox.com>

 the case is exactly equal for all three cases - Body entries, 
Header entries, Detail entries.
 In any case you can have a no-target-namespace schema to account 
for unqualified entries. So we can achieve consistency either 
way. My preference is to mandate qualification, as I indicated in 
the last quoted sentence using other words.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation

On Fri, 19 Jul 2002, Pete Hendry wrote:

 > Jacek Kopecky wrote:
 > > In fact, why is it necessary that Body entries be qualified? 
 > >
 > For validation. It is required that the element name in the body be 
 > resolvable to a schema element definition (assuming schema as the type 
 > system of course) so that validation can proceed on the body contents. 
 > Because the body is defined as <any> either there must be an xsi:type on 
 > all the body elements (which is not currently required - and not 
 > possible for rpc) or the element name must be resolvable.
 > Keep it qualified!
 > >
 > >Same for header entries. 8-) If anyone is worried their name 
 > >could be conflictful, they would namespace-qualify it. 8-)
 > >
 > Same again if you want validation (which the service provider decides 
 > rather than the client so you don't want the option of non-qualified 
 > header entries being given to the client).
 > >
 > > I'm for consistency here, and it seems the easier way to achieve 
 > >it will be to change Fault/Detail/* rules. 8-)
 > >
 > Again for detail entries, where their names should allow finding their 
 > element definition in the schema. They should only be unqualified if 
 > their schema definition is in the no-namespace-schema.
 > Pete
Received on Friday, 19 July 2002 04:05:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:20 UTC