RE: Formalism in SOAP spec

Thanks for the interest in my comments.

I'm not sure if I am adressing your comment correctly, but the way that
EBNF is used in the XML schema specification is in my opinion (and
others around here) also not appropriate.  EBNF is used partially in the
XML schema document but then commentary is used to qualify (read change)
what the grammer specifies.  This is to me unacceptable.  So yes I agree
that there is a fundamental problem.  However I'd really like to focus
on SOAP, my colleague Tim MacAndrew is knowledgable about XML Schema and
the problems therein, so I am copying him.

I really think there is a serious issue here.  One important purpose of
a standard is interoperability and for that you must have rigerous
formalization.  Also the more complex you make the constructs the less
likely compliance will be.  

The IETF provide a pretty good template for specification.  At the
begining of the document they have a description of EBNF grammer and
what the magic characters mean (?,*,+...).  Then they stick to using
that grammer.

To look at SOAP 1.2, section 4.4.2 Arrays in detail however.

The first example has a Schema.  Why it is there? Do we need to define a
schema for a SOAP message? Do we care about conformance to a schema.
There is unfortunately no explanation or motivation for providing this.
What do you expect a reader without apriori information to get from this
example.  The second example is apparently SOAP fragment conforming to
the schema, or is it?  It does not seem to be a correct SOAP fragment
because it is missing the xsi:type="enc:Array" attribute.  Or are we
supposed to infer that it is an array from the enc:arrayType attribute.
Of course we don't really know what this is since the title of the
example is Array conforming to the preceding Schema which tells us
nothing about whether it is a SOAP document fragment or not.  Also in
this example we note that the size of the array is specified in the
array declaration and we can also determine the array size from the
number of contained elements.  The size is over specified, which is okay
but what are we supposed to do if the sizes don't match.  What would we
do in the case of conflict which would take precedence?  Or would we
produce a fault, if we produce a fault, what fault, shouldn't it be a
predefined fault.  Next is an example showing an alternative method for
defining SOAP arrays.  I see no reason why an EBNF couldn't be defined
for this, such as (at the risk of embarrassing myself)

<array> ::= <named_array> | <unnamed_array>
<named_array> ::= "<"...
<unnamed_array> ::= "<" <enc> ":" "Array" ...

And you know if you can't figure out a way of specifying this using EBNF
maybe the problem is that the syntax for array is flawed.
Furthermore the encoding schema does not say that any of the attributes
are required and there is no default specified if nothing is specified.
Finally there is no documentation in the encoding schema explaining the
meaning of each of the attributes.  

The next example has to do with polymorphism.  But in the description
above it says I can use "user-defined derivation of integer" but it
doesn't have any description of how I would create this type.  How would
I for example create a prime integer and then use it.  

I could go on, but I think you get the point.  Please note I do wish to
give the impression that the problems are restricted to arrays.

Matthew Jones
mjones@netsilicon.com 

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: Wednesday, November 14, 2001 8:24 AM
> To: Noah_Mendelsohn@lotus.com; xml-dist-app@w3.org
> Cc: Jones, Matthew
> Subject: RE: Formalism in SOAP spec
> 
> 
> 
> I may misunderstand the intent but it seems that the 
> discussion hints at
> XML schema not being useful for formally defining the structure of the
> envelope and that we instead should be using EBNF. If the question
> really is to use schema or not then I think that is a more fundamental
> discussion that seems to apply to more than just SOAP.
> 
> Henrik Frystyk Nielsen
> mailto:henrikn@microsoft.com
> 
> >-----Original Message-----
> >From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com] 
> >Sent: Wednesday, November 14, 2001 07:24
> >To: xml-dist-app@w3.org
> >Cc: MJones@NetSilicon.com
> >Subject: Formalism in SOAP spec
> >
> >
> >Note that the following comments end with a call for more 
> >formalism and precision in the specfication.  While not a 
> >specific endorsement of the current proposed binding 
> >framework, it does appear that at least some of our 
> >"customers" are looking for specifications that are more 
> >precise and formal.
> >
> >---------------------------------------------------------------
> >---------
> >Noah Mendelsohn                                    Voice: 
> >1-617-693-4036
> >Lotus Development Corp.                            Fax: 
> 1-617-693-8676
> >One Rogers Street
> >Cambridge, MA 02142
> >---------------------------------------------------------------
> >---------
> >
> >
> >
> >----- Forwarded by Noah Mendelsohn/CAM/Lotus on 11/14/01 
> 10:22 AM -----
> >                                                               
> >                                                        
> >                    "Jones, Matthew"                           
> >                                                        
> >                    <MJones@NetSilicon        To:     
> ><xmlp-comments@w3.org>                                           
> >                    .com>                     cc:     (bcc: 
> >Noah Mendelsohn/CAM/Lotus)                                 
> >                    Sent by:                  Subject:     
> >Comments on the SOAP 1.2 Specification                      
> >                    xmlp-comments-requ                         
> >                                                        
> >                    est@w3.org                                 
> >                                                        
> >                                                               
> >                                                        
> >                                                               
> >                                                        
> >                    11/09/01 01:13 PM                          
> >                                                        
> >                                                               
> >                                                        
> >                                                               
> >                                                        
> >
> >
> >
> >I have the following comments on the SOAP 1.2 Part 2: 
> Adjuncts document
> >
> >1.  There is no grammar for describing the structure of a SOAP 
> >Message. There should be a rigorous definition of the 
> >structure of the document. The definition of the structure 
> >should include the standard encoding. The document 
> http://www.w3.org/2001/09/soap-encoding is not adequate. The preferred
> strategy would be an EBNF grammar.  I do not feel the Schema is up to
> the task and since a SOAP document contains fragments there is
> circularity or ambiguity issue.
> 
> 2.  Section 4.4.2 does not describe how to encode arrays.  The first
> example in that section shows a schema and an xml document 
> conforming to
> that schema.  It has nothing to do with SOAP encoding.  There is no
> reason to ever put an XML Schema in this section it only confuses the
> issue, and there is no motivation or explanation why they are there.
> What should be there is a rigorous specification of the various ways
> that an array can be defined uses that standard encoding.  Providing
> multiple examples and lazy and doesn't belong in the core of a
> specification (an appendix maybe).  If you can't figure out how to
> provided a rigorous specification using, for example, and EBNF then it
> is not ready for standardization.
> 
> Virtually every section has a similar problem to sections 4.4.2.
> 
> I you are serious about providing a useful specification then you will
> rewrite the specification to make it a formal specification 
> rather than
> a document full of commentary and examples.
> 
> Matthew Jones
> mjones@netsilicon.com
> 
> 
> 
> 
>

Received on Wednesday, 14 November 2001 12:55:03 UTC