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