LOTP Discussions

This is the LOTP (Layered Object Transport Protocol) Discussion document. It contains a transcript of discussions about various points in the LOTP specification.

The URI for this document is http://www.w3.org/2000/03/31-LOTP-Discussion. Do not include the ".html" extension in any references to this document as it will probably become a scipt.

arguments that support the annotated issue

questions pertaining to the annotated issue

arguments that oppose the annotated issue

topic	disposition	who	see also
common overloadable objects		Eric Prud'hommeaux	see also
The common locations provide application interoperability by giving all applications the ability to look for, for instance, the authentication information in the same place. The overloadability allows an one application to require an SSL encrypted message while another requires only simple plaintext password. A message with a plaintext password may travel across a non-secure piece of the network if generic LOTP proxy agents at either end encrypt and decrypt the password or replace it with a one time password, etc.
foreign required directives		Eric Prud'hommeaux
Will foreign required directives lead to more fragmentation, or just give people the tools to fix unexpected requirements in the protocol? - my guess is the latter, but it bears study.
default to mandatory namespaces		Eric Prud'hommeaux	Viewpoints document
The streamlined application designer will often choose not to include any required namespace directives. The only safe thing for the naive application to do with such a message is to abort if it does not understand every unspecified namespace.
errors without backchannel		Eric Prud'hommeaux
By defining error codes without defining a transport mechanism, we allow the generic interpretation and overloading of error conditions without requiring any additional functionality of the backchannel transfer adapter. While immediate error responses through an HTTP transfer adapter would likely be passed as the HTTP response, they may not be generated in time or the origonating message may have arrived via SMTP.
module evolution expedience		Eric Prud'hommeaux
The work in outlining a minimal framework for extensibility is small compared to the time and effort in defining the boundries between many orthogonal extensions. By specifying the extension framework, encouraging at lease message conformance, and providing a useful set of suggested modules, we can move forward more quickly with core deployment and give the modules a starting point for discussion and evolution.
why define agent conformance		Eric Prud'hommeaux
agent conformance assures that an agent is able to handle the unknown namespace criteria.
XSLT protocol adapters		Eric Prud'hommeaux	Don Box's XML-RPC to SOAP transforms Henrik Frystyk Nielsen's message about this.
There may be some benefit to specifying a standard sttribute and value to include in non-LOTP documents to specify the location of an XSLT stylesheet that will transform that foreign message to a LOTPconformant message. I'd like to put up a page of XSLT transformations between LOTP and other protocols. Anybody out there good at XLST and want to help?
reference model		Eric Prud'hommeaux	note to xml-dist-app
I'm interested in the screw case of serializing two structures that have pointers to each others nested structures. While the copy implied with this may seem wasteful, it is necessary in any model that allows included data to be referenced.
multiple inheritance in LOTP		Eric Prud'hommeaux
Multiple inheritance is a great way to complicate languages, but I beleive it is worthwhile in LOTP's case. Java solved the issue by separating the class data structure from the class methods and allowing a class to inherit data from only on other class. While in Java, the functionality comes from the class methods, LOTP is strictly data-oriented and benifits from multiple interfaces only if it can embed that data for these interfaces. I beleive that a simple data-inclusion model of multiple inheritence does not overly complicate LOTP, and presents a much richer set of functionality to application and schema designers. @@check to see if XMLSchema support multipl subclassof directives@@
conflicting base classes		Eric Prud'hommeaux
If cases arrise where multiple schema designers reuse common tags with different meaning, the orginal schema was probably underdefined or misinterpreted.
standard types		Eric Prud'hommeaux	see also
Simeon Simeonov and Glen Daniels promoted standardization through providing a common vocabulary of header slots for these elements (except Exception and Deferment.
standard connection type		Eric Prud'hommeaux	see also
I am not sure about the utility in standardizing this header. I could use some convincing either way.
avoiding array opacity		Eric Prud'hommeaux
By making array specifiers a series of atomic attributes, they become available for XSLT transformations. Compare to the SOAPv1 form of: <ArrayOfArrayOfString xsd:type="u:string[][2]"> <ArrayOfString href="#array-1"/> <ArrayOfString href="#array-2"/> </ArrayOfArrayOfString> <ArrayOfString id="array-1" xsd:type="u:string[3]"> <string>r1c1</string> <string>r1c2</string> <string>r1c3</string> </ArrayOfString> <ArrayOfString id="array-2" xsd:type="u:string[3]"> <string>r2c1</string> <string>r2c2</string> </ArrayOfString> The u:string[][2] requires and infinted or dynamic vocabulary of types as each array construction is a unique type.
untyped arrays		Eric Prud'hommeaux	see also
Naturally, I am not enthralled about not being able to type array elements until reaching the innermost elements. While in Java, non-homgeneous arrays are the norm, this is not the case in more nuts and bolts languages like pascal and C. Perhaps an extra tag could be used to give a hint of homogeneity where appliciable?

Eric Prud'hommeaux,