Re: Re: new version of requirements following ARTF telcon of 2003-01-15

Chris,
 
These aren't really my requirements at this point, but the ARTF's.  I 
can try to shed a little light though.  See the <mark> comments below.

-------------------------------------------------------------------------
 
> * The specification should aid debugging with simple tools.  
 
This has me baffled. What is it that you have in mind in the way of
tools, and more specifically, are you suggesting that the
specification would define said tools or that the specification would
define a concrete binding that had as a design consideration that an
implementation would be inherently debuggable? Further, what manner of
"debugging" are we talking about here?

<mark>John Barton suggested this one and his reply to your note 
captures his intention.</mark>
 
 
>  
> R15. The specification should not unecessarily preclude convenient 
>       description by languages such as WSDL.  
 
Hmmm... Why wouldn't the specification provide a normative WSDL binding  
extension mechanism? Afterall, what authority is better suited to  
define the extension than that which specifies the concrete binding  
itself?  
 
Yes, I realize this is the XMLP WG and not the WSDL WG, but the WSDL  
WG is not chartered with the specification of all WSDL extensions, just 
the WSDL core syntax, processing model, extension points and framework.  
 
It seems to me that not defining the WSDL binding extension for this  
feature would be like the XMLP defering a schema definition of SOAP  
to the XML Schema WG. Clearly, we would not do that, why would we defer 
the definition of the WSDL? 

<mark>Jean-Jacques's reply touched on some of this.  Noah suggested
the somewhat convoluted wording to try to convey the sense that WSDL
is still evolving and that it may need to stretch a bit also.  (We
won't necessarily need the flexibility, but this gives us a litle
wiggle room.) </mark>
 
>  
> DR3. The specification must admit a reasonably time-efficient means 
of 
>      identifying parts.  
 
I think that rather than "identifying" this is intended to refer to  
resolving or dereferencing, no? If not, then I guess I don't understand 
the requirement's indended interpretation. 
 
<mark> "identifying" in this sense is more tied to finding parts in
the packaging -- byte lengths, boundary strings, etc.</mark>
 
>  
> DR5. The representation must efficiently support the addition and 
>      deletion of parts.  
 
Hmmm... While it is clear that an implementation of the specification  
would likely carry this requirement, it is less than clear that the  
requirement is applicable to the specification itself. Further, one 
would imagine that by this statement, it would be the intended to cover the  
insertion or in-line deletion of parts, or had you only appending and  
truncation in mind?  
 
Again, it isn't clear that this requirement, as written is either  
testable of a specification or relevant for a specification that is not  
intended to be implementation-specific. 

<mark> The point here was to make the spec relatively friendly to
intermediaries that might need to modify the attachment bundle in
straightforward ways.  (roughly resonant with the fact that insertions
and deletions of headers in a SOAP envelope are pretty straightforward
syntactically, for example). </mark>
 
 
>  
> DR13. The specification must provide support for large parts.  
 
And small ones as well one would imagine. How large? Arbitrarily  
large? Just "pretty big", really, really large" or "incomprehensibly  
large"? :)  
 
What about parts who's size is not known at the time that  
the serialization is begun? 

<mark>These points have been discussed briefly.  This one needs more 
work. </mark> 

>  
> Reference to Parts 
>  
> DR6. The specification must permit parts to be identified by URIs.  
 
Hmmm... I think that the specification should require that parts be  
identified by URI, but that they may be identified using other means  
as well. Of course, they could be identified by relative URI, not just 
absolute URI. 

<mark> We can consider your wording instead. </mark> 

>  
> DR11. (a) The specification should permit an initial human readable 
>           part. 
>       (b) The specification should not specify a particular ordering 
>           of parts. 
>       [still noodling on which version to prefer]  
 
Not sure I follow this... 

<mark>There was some sentiment for flexibility in part ordering -- for
example, having a text part preceeding even the SOAP message.</mark>
 

> DR12. The SOAP message part should be readily 
locatable/indentifiable.  
 
Should it not be the case that ALL parts be identified, identifiable?  
What would make the SOAP part unique in this regard? 

<mark> We wanted to make sure if there were multiple SOAP message
parts that we could identify which one was the primary part and which
were attachments.  This may be an issue if order were arbitrary, for
example.</mark>
 
>  
> DR16. The part identifier scheme to be detremined by sending 
>       application.  
 
"scheme" seems to imply "URI", but my guess is that it does not.  
Again, I would strongly recommend that parts be identified by URI  
(relative or absolute).  
 
<mark>URI is what I have in mind.</mark>


Thanks for the comments.
--mark
_____________________

Mark A. Jones
AT&T Labs -- Strategic Standards Division
Shannon Laboratory
Room 2A02
180 Park Ave.
Florham Park, NJ  07932-0971

email: jones@research.att.com
phone: (973) 360-8326
  fax: (973) 236-6453

Received on Monday, 20 January 2003 22:03:53 UTC