Re: Processor conformance: fault on non-conformant input

David Booth wrote:

>
> Sanjiva,
>
> As far as I know, you are the only one who was in favor of REQUIRING 
> the processor to fault if there is ANY part of the WSDL document that 
> is non-conformant, even if that part of the document is not needed 
> (for example, if it is in a different binding).  So if I've understood 
> other people's responses, it looks like others agree with the wording 
> I proposed for the bullet item in section 7.3., which was to change:
> [[
> A conformant processor MUST fault if presented with a
> non-conformant WSDL 2.0 document.
> ]]
> to:
> [[
> A conformant WSDL processor MUST fault if a portion of a WSDL
> document is illegal according to this specification and the
> WSDL processor attempts to process that portion.
> ]]
>
> (Bear in mind that unless we say something to the contrary,  a 
> conformant processor MAY fault if an unneeded portion of a WSDL 
> document is illegal.  Unless we explicitly prohibit such behavior, 
> then it would be allowed by default.)
>
> Are you sure you want to REQUIRE every conformant processor to fault 
> on any illegal but unneeded portion of the WSDL document?  As I 
> pointed out in
> http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0219.html
> such a requirement would be a departure from the approach we're taking 
> for mandatory extensions.

I am not sure that Sanjiva is alone. Here are my concerns.

If a processor is not required to process all aspects of the WSDL 
document, then it is impossible, technically, to find out whether a 
document is conformant or not, because "conformant" processors may 
choose to ignore certain portions of a document and end up not reporting 
errors. Note that by "sheer ignorance" (as it is bliss ;-)), it is 
equivalent to consume or ignore a specific portion of a document. If it 
is valid/legal, you are conformant by default, if it is not, well you 
are allowed to ignore certain portions of it. Nice!

Based on this definition, a document may not be conformant but the 
processor will be. So, what is the purpose of defining a conformant 
processor? A processor that can handle valid WSDL documents and more or 
a processor that will reject invalid WSDL documents?  It seems that a 
conformant processor is NOT the processor that may be able to reject a 
non-conformant document by this change. That is a completely a different 
beast, maybe a uber-conformant processor that MUST process all the WSDL 
document and MUST fault if it is a non-conformant document. There is a 
need to define such a processor category if our conformant processor 
definition is not targeted to do this. I was under the impression that  
we wanted to align the conformance of a processor to align 
with/determine a document's conformance.

What I don't like in your change of definition is that "how a portion" 
is defined for processing is very opaque and unfortunately meaningless 
unless we define exactly what it is.  It is equivalent to, IMO, to 
saying nothing at all. The problem is defining what that subset is, 
namely the set of "portions" of a WSDL document that a conformant 
processor MUST process. Unless we define this set precisely, which is a 
"profile" by the way, the conformant processor definition, IMO, is not 
going to be that definitive.


Cheers,

--umit

Ps. I would like to also point out that there are two terms used in the 
processor conformance section, 8.3. "fail" (bullet 4) and fault (in 
other bullets). The definition of what "faulting" means (immediately 
cease processing) is explored only in bullet 5. I suggest moving it to 
bullet 2 as an editorial change, so that the definition comes before the 
usage.

>
>
>
> At 09:17 PM 3/22/2004 +0600, Sanjiva Weerawarana wrote:
>
>> OK so what's the verdict on this thread? David Booth can you
>> please give a summary and recommendation?
>>
>> THanks,
>>
>> Sanjiva.
>
>

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com

Received on Monday, 22 March 2004 21:04:04 UTC