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

Mark,

Please see my comments below.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

xml-dist-app-request@w3.org wrote on 01/15/2003 12:10:13 PM:

> 
> Here is another list of requirements following the ARTF (Attachment
> Requirements Task Force) telcon held from 11am-noon EST on Jan. 15,
> 2003.  A couple of former draft requirements have been moved forward
> to "Considerations" instead.  Those requirements marked "DR" have not
> yet been discussed in detail by the task force; those requirements
> marked "R" have achieved consensus within the task force.
> 
> 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
> 
> ================================================================
> 
> Concrete Attachment Feature Requirements
> ----------------------------------------
> 
> Considerations
> 
> * The specification should not invent a packaging scheme.

Agreed.

> * 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?

> 
> 
> General Requirements
> 
> R8. The specification must describe its relationship to the
>      properties defined in Table 1 (att:SOAPMessage and
>      att:SecondaryPartBag) in the SOAP 1.2 Attachment Feature
>      specification.
> 
> R9. The specification must describe its points of extensibility.
> 
> 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?

> 
> DR17. The specification must work with the SOAP 1.2 HTTP binding and
>       with as many other bindings as possible.
> 
> 
> 
> Representation
> 
> DR1. The specification must define a means to carry multiple data parts.
> 
> DR2. The specification must define a means for parts to carry
>      arbitrary data, including non-XML data (e.g., binary data and XML
>      fragments).
> 
> 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.

> 
> DR4. The specification must use a reasonably space-efficient
>      representation.
> 
> 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.

> 
> 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?

> 
> 
> 
> 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.

> 
> DR7. The URI identification scheme must be robust under the addition
>      and deletion of parts -- i.e., it must not require that URIs to
>      other parts be altered, it must be relatively easy to avoid URI
>      conflicts, etc.
> 
> 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...

> 
> 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?

> 
> 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).

>