[Smartfrog-checkins] core/extras/alpine/doc/jaxrpc alpine.tex,1.16,1.17 bibliography.bib,1.18,1.19 implications.tex,1.8,1.9 introduction.tex,1.18,1.19 objections.tex,1.23,1.24 wsdl.tex,1.13,1.14

[Steve L. <st...@us...>]

Update of /cvsroot/smartfrog/core/extras/alpine/doc/jaxrpc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9672/alpine/doc/jaxrpc

Modified Files:
	alpine.tex bibliography.bib implications.tex introduction.tex 
	objections.tex wsdl.tex 
Log Message:
more text, more references. Need to fix layout

Index: introduction.tex
===================================================================
RCS file: /cvsroot/smartfrog/core/extras/alpine/doc/jaxrpc/introduction.tex,v
retrieving revision 1.18
retrieving revision 1.19
diff -C2 -d -r1.18 -r1.19
*** introduction.tex	25 Apr 2005 22:29:05 -0000	1.18
--- introduction.tex	26 Apr 2005 13:52:53 -0000	1.19
***************
*** 85,98 ****
  In JAX-RPC\footnote{The current edition of the JAX-RPC specification
  is version 1.1, and this is the version we discuss here. JAX-RPC 2.0
! is discussed in section \ref{implications:future}.}, the XML representation of
! how a message is hidden; the developer works with
! Java objects created automatically from the XML data using a
! semi-standardised mapping process. Java classes can be automatically
! turned into SOAP endpoints, with each public method in the class
! exported as an operation with a request message and a response
! message. The message structure is described in a WSDL descriptor and an
! associated XML Schema, both of which can
! be hand-written, or automatically extracted from the Java classes
! through introspection.
  
  Client side proxy classes can be generated from the WSDL files, proxy
--- 85,96 ----
  In JAX-RPC\footnote{The current edition of the JAX-RPC specification
  is version 1.1, and this is the version we discuss here. JAX-RPC 2.0
! is discussed in section \ref{implications:future}.}, 
! the XML representation of how a message is hidden; the developer works with Java
! objects created automatically from the XML data using a semi-standardised
! mapping process. Java classes can be automatically turned into SOAP endpoints,
! with each public method in the class exported as an operation with a request
! message and a response message. The message structure is described in a WSDL
! descriptor and an associated XML Schema, both of which can be hand-written, or
! automatically extracted from the Java classes through introspection.
  
  Client side proxy classes can be generated from the WSDL files, proxy
***************
*** 143,149 ****
  needed to make it comprehensible. That it takes so many lines to
  describe a relatively simple service is clearly one reason why this
! approach, despite its alleged superiority of output, is so unpopular.
  
! Many problems were encountered turning this WSDL specification into
  functional clients and servers, problems that we attribute to JAX-RPC.
  In section \ref{objections} we discuss a number of the problems we
--- 141,147 ----
  needed to make it comprehensible. That it takes so many lines to
  describe a relatively simple service is clearly one reason why this
! approach, is so unpopular.
  
! Many problems were encountered turning this service specification into
  functional clients and servers, problems that we attribute to JAX-RPC.
  In section \ref{objections} we discuss a number of the problems we

Index: implications.tex
===================================================================
RCS file: /cvsroot/smartfrog/core/extras/alpine/doc/jaxrpc/implications.tex,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** implications.tex	25 Apr 2005 22:29:05 -0000	1.8
--- implications.tex	26 Apr 2005 13:52:53 -0000	1.9
***************
*** 40,77 ****
  \cite{spec:J2EE-14}, alongside RMI and RMI-over-CORBA. That is not by
  itself a bad thing, but we believe that it creates the misconception
! that developers can trivially migrate from RMI to web services. If
  they attempt to do, they will fall into the traps that JAX-RPC creates
  for them.
  
! The forthcoming 2.0 release of the JAX-RPC specification promises to
! correct some of these flaws, it is unclear whether it corrects
! sufficiently many of them. An alternate O/X mapping, JAX-B, the Java
! Architecture for XML Binding, is introduced which is a compile-time
! declaration of what XML is to be expected, but is independent of the
! SOAP stack. The 2.0 release also retains the core metaphor of service
! calls as method invocation, with the payload of most invocations
! being Java objects that are somehow mapped to XML content. The
! automated generation of WSDL from Java source is retained, despite
! this approach having been shown to be fundamentally flawed.
  
! We understand the rationale for much of this. Working with raw XML is
! hard.  Writing good XML Schema documents is hard. WSDL is exceedingly
! painful to work with. However, we believe that if developers do not
! create the XSD and WSDL definitions of their service, they will never
! have control of the messages that get sent over the wire, and that
! without that control, interoperability and loose coupling will remain
! out of reach.
  
  The next version of Apache Axis, Axis 2.0, has adopted a more XML-centric design
! than before. The XML representation of a message is represented in the Message
! Object Model, \emph{MOM}, which is intended to be simpler than DOM, yet still a
! usable representation of messages. Extensions to the core runtime are expected
! to provide the mapping between the MOM tree and Java object graphs, with this
! mapping being an optional way of working with messages, rather than the standard
! mechanism. We admire this change in direction, and believe that this
! architecture could be a foundation for more robust SOAP server and client
! applications. However, the fact that O/X mapping and contract-last development
! are still enabled within the infrastructure imply that users are still being
! encouraged to write their code and have the SOAP stack handle the marshalling.
! This is precisely what we believe is a mistake.
  
--- 40,104 ----
  \cite{spec:J2EE-14}, alongside RMI and RMI-over-CORBA. That is not by
  itself a bad thing, but we believe that it creates the misconception
! that developers can trivially migrate from RMI to SOAP. If
  they attempt to do, they will fall into the traps that JAX-RPC creates
  for them.
  
! The 2.0 revision of the JAX-RPC specification promises to correct some of these
! flaws, but not, we fear, enough. It uses a new O/X mapping, the Java
! Architecture for XML Binding 2.0 9 (JAXB 2.0)\cite{spec:JAX-B-20}. This is possibly the most
! sophisticated XML to Java mapping framework yet designed, with broad support
! for generating classes from XML Schema, and XML Schema from annotated classes.
! It is, however, still an O/X mapping technology; something we have argued is
! inherently flawed.  
!  
! JAX-RPC 2.0 retains the metaphor of method-invocation of an object instance, with
! a payload of Java objects that are somehow mapped to and from XML content. This
! and the automated generation of WSDL from Java source, means that it still
! retains the pretense of enabling communication between Java programs, using Java
! objects. This is the metaphor that lies at the root of much of JAX-RPC's
! problems.
  
! We understand the rationale for design decisions of JAX-RPC and JAXB 2.0. Working
! with raw XML is hard. Writing good XML Schema documents is hard. WSDL is
! exceedingly painful to work with. Asynchronous messaging is more complex than
! blocking RPC calls. Yet we believe that all these things need to be done, else
! interoperability and loose coupling will remain unrealised.
  
  The next version of Apache Axis, Axis 2.0, has adopted a more XML-centric design
! than its predecessors. A message is represented in the Message Object Model,
! \emph{MOM}, which is intended to be simpler than DOM, yet still a usable
! representation of messages. Extensions to the core runtime are expected to
! provide the mapping between the MOM tree and Java object graphs, an
! implementation of JAXB 2.0 being the primary such extension. We admire this
! change in direction, and believe that this architecture could be a foundation
! for more robust SOAP server and client applications. However, the fact that O/X
! mapping and contract-last development are still enabled within the
! infrastructure implies that users are still being encouraged to write their code
! and have the SOAP stack handle the marshalling. 
! 
! Finally, WSDL itself is evolving; WSDL2.0 is nearing the end of its
! specification process \cite{spec:WSDL-20}. Will a new WSDL syntax make it easier
! to specificy service contracts. We certainly hope it will, and can see that some
! aspects of the language, such as the {\tt interface} construct will make it
! easier to reuse and extend other service interfaces. Unfortunately, the sheer
! broadness of the goals of WSDL ---a language to specify arbitrary
! XML-based communications across multiple protocols--- makes it exceedingly
! complex. WSDL 2.0 still appears to require repeated declarations of a similar
! syntax, first the abstract operations, then the actual binding, and many, many,
! XML messages need to be defined. In handwritten WSDL, the risk of errors is
! high, and the ease of tracking down the problems low. As any SOAP stack
! developer will certify, bug reports involving handwritten WSDL are the ones they
! fear. 
! 
! If the broadness of WSDL is a key problem, then a possible solution would be to
! define a subset of interoperable WSDL; this is essentially what the Web Service
! Interoperability (WS-I) group have done. One could then design a minimal service
! description language that only covered this subset, a new XML language that
! could be turned into valid WSDL though an XSL transformation. This could be a
! workable solution to the problem of making it easy to write WSDL: a
! human-writeable language that had a one-way transformation into valid WSDL 1.1
! or 2.0. We may explore this concept.
! 
! 
! 
  

Index: wsdl.tex
===================================================================
RCS file: /cvsroot/smartfrog/core/extras/alpine/doc/jaxrpc/wsdl.tex,v
retrieving revision 1.13
retrieving revision 1.14
diff -C2 -d -r1.13 -r1.14
*** wsdl.tex	25 Apr 2005 22:29:06 -0000	1.13
--- wsdl.tex	26 Apr 2005 13:52:53 -0000	1.14
***************
*** 15,30 ****
  managed with respect to versioning.
  
! \item Secondly, the act of writing an IDL description inherently
! forces the author to define the system in terms of the portable
! datatypes and operations available in the restricted language of the
! IDL.  This can effectively guarantee portability, and is a significant
! improvement over similar definitions in implementation languages,
! which invariably contain constructs which are not portable. As such
! constructs are excluded from the interface language, a portability
! issue is the exception, rather than being commonplace.
  \end{enumerate}
  
  IDLs have many advantages for creating interoperable systems, yet the
! generally accepted practise for working with JAX-RPC discards all
  these notions. Instead of generating implementation classes from WSDL,
  the WSDL description is usually generated from the implementation
--- 15,29 ----
  managed with respect to versioning.
  
! \item Secondly, the act of writing an IDL description forces the author to
! define the system in terms of the portable datatypes and operations available in
! the restricted language of the IDL. This can effectively guarantee portability,
! and is a significant improvement over interfaces defined in the implementation
! languages themselves, which invariably contain constructs which are not
! portable.
! 
  \end{enumerate}
  
  IDLs have many advantages for creating interoperable systems, yet the
! generally accepted practice for working with JAX-RPC discards all
  these notions. Instead of generating implementation classes from WSDL,
  the WSDL description is usually generated from the implementation
***************
*** 41,45 ****
  remains constant over time. Every redeployment of the service, every
  upgrade of the SOAP stack or even the underlying Java runtime may
! change the WSDL, and hence the interface.
  
  \item
--- 40,44 ----
  remains constant over time. Every redeployment of the service, every
  upgrade of the SOAP stack or even the underlying Java runtime may
! change the classes, and hence the contract.
  
  \item
***************
*** 93,97 ****
  
  We are not proposing any changes to WSDL, merely mourning the fact
! that its over-complexity discourages contract-first, contract-driven
  development more aggressively than any previous IDL ever did. We do
  observe that once the type declarations of a service have been moved
--- 92,96 ----
  
  We are not proposing any changes to WSDL, merely mourning the fact
! that its over-complexity discourages contract-driven
  development more aggressively than any previous IDL ever did. We do
  observe that once the type declarations of a service have been moved

Index: bibliography.bib
===================================================================
RCS file: /cvsroot/smartfrog/core/extras/alpine/doc/jaxrpc/bibliography.bib,v
retrieving revision 1.18
retrieving revision 1.19
diff -C2 -d -r1.18 -r1.19
*** bibliography.bib	25 Apr 2005 22:29:05 -0000	1.18
--- bibliography.bib	26 Apr 2005 13:52:52 -0000	1.19
***************
*** 55,63 ****
      }
      
! @techreport{spec:WSDL2.0,
      title="Web Services Description Language {(WSDL)} Version 2.0 Part 1: Core Language",
      institution="W3C",
      author="Roberto Chinnici",
!     year=2004
      note="http://www.w3.org/TR/2004/WD-wsdl20-20040803",
      }          
--- 55,63 ----
      }
      
! @techreport{spec:WSDL-20,
      title="Web Services Description Language {(WSDL)} Version 2.0 Part 1: Core Language",
      institution="W3C",
      author="Roberto Chinnici",
!     year=2004,
      note="http://www.w3.org/TR/2004/WD-wsdl20-20040803",
      }          
***************
*** 85,90 ****
      note="http://www.oasis-open.org/committees/relax-ng/spec-20011203.html",
      }
!         
! 
  @techreport{spec:JAX-RPC-11,
      institution="Java Community Process", 
--- 85,89 ----
      note="http://www.oasis-open.org/committees/relax-ng/spec-20011203.html",
      }
!     
  @techreport{spec:JAX-RPC-11,
      institution="Java Community Process", 
***************
*** 96,99 ****
--- 95,99 ----
      }
  
+     
  @techreport{spec:JAX-M-10,
      institution="Java Community Process", 
***************
*** 105,108 ****
--- 105,117 ----
      }
      
+ @techreport{spec:JAX-B-20,
+     institution="Java Community Process", 
+     title="{Java API for XML Binding (JAXB)}",
+     edition="2.0",
+     year=2004,
+     author="Nicholas Kassem and Anil Vijendran and Rajiv.Mordani",
+     note="http://java.sun.com/xml/downloads/jaxrpc.html"
+     }
+     
  @techreport{spec:JAX-M-11,
      institution="Sun Microsystems", 
***************
*** 162,166 ****
      }
  
!     
  @techreport{ietf:rfc2616,
      title="{RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1}",
--- 171,183 ----
      }
  
! @techreport{spec:WSI-11,
!     institution="WS-i",
!     author="keith Ballinger", 
!     title="{Basic Profile}",
!     edition="1.1",
!     year="2004"
!     note="http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html"
!     }
!   
  @techreport{ietf:rfc2616,
      title="{RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1}",
***************
*** 253,263 ****
      }
  
! @techreport{spec:RelaxNG,
!     title="{RELAX NG} Specification",
!     institution="Oasis",
!     author="James Clark",
!     year=2001
!     note="http://www.relaxng.org/spec-20011203.html",
!     }          
      
  
--- 270,274 ----
      }
  
!     
      
  

Index: objections.tex
===================================================================
RCS file: /cvsroot/smartfrog/core/extras/alpine/doc/jaxrpc/objections.tex,v
retrieving revision 1.23
retrieving revision 1.24
diff -C2 -d -r1.23 -r1.24
*** objections.tex	25 Apr 2005 22:29:05 -0000	1.23
--- objections.tex	26 Apr 2005 13:52:53 -0000	1.24
***************
*** 236,241 ****
  
  If more metadata were recorded with generated types, this problem would not
! arise. We therefore expect that future versions of JAX-RPC will address this 
! problem by way of the code annotation facility recently added to the Java
  language. 
  
--- 236,241 ----
  
  If more metadata were recorded with generated types, this problem would not
! arise. We therefore believe that future versions of JAX-RPC will address this 
! problem by way of the annotation facility recently added to the Java
  language. 
  
***************
*** 260,265 ****
  matches their expectations given the schema. This requires an
  understanding of the schema, knowledge of the serialisation mapping
! and its potential trouble spots, the willingness to write the tests to
! validate this extra logic, and most of all, the time to do so.
  
  \end{enumerate}
--- 260,265 ----
  matches their expectations given the schema. This requires an
  understanding of the schema, knowledge of the serialisation mapping
! and its potential trouble spots, and the willingness to write the tests to
! validate this extra logic.
  
  \end{enumerate}
***************
*** 341,353 ****
  \label{objections:soap-not-just-rmi}
  
! SOAP's parentage includes XML-RPC \cite{winer:xmlrpc} and (indirectly)
! COM/DCOM \cite{dbox:SoapHistory,dbox:com} and CORBA
! \cite{vinoski:CORBA}. It was clearly designed at its outset to be a
! form of remote procedure call in XML, over HTTP. Over time, the
! world-view that lead to that choice has changed. Though it is often
! presented as a form of RPC, we would argue that it is coming to be
! seen as more powerful when viewed as a system where arbitrary XML
! documents are exchanged between parties, perhaps asynchronously,
! and potentially via intermediaries.
  
  In this world, the programming paradigms that seemed appropriate for
--- 341,351 ----
  \label{objections:soap-not-just-rmi}
  
! SOAP's parentage includes XML-RPC \cite{winer:xmlrpc} and (indirectly) COM/DCOM
! \cite{dbox:com} and CORBA \cite{vinoski:CORBA}. It was clearly designed at its
! outset to be a form of remote procedure call in XML, over HTTP. Over time, the
! world-view that lead to that choice has changed. Though it is often presented as
! a form of RPC, we would argue that it is coming to be seen as more powerful when
! viewed as a system where arbitrary XML documents are exchanged between parties,
! perhaps asynchronously, and potentially via intermediaries.
  
  In this world, the programming paradigms that seemed appropriate for
***************
*** 394,412 ****
  Java RMI. Java's RMI system is a simple and effective mechanism for
  connecting Java classes running on different machines. It is an
! IDL-free communication mechanism, which relies on introspection to
! create proxy classes and to marshal classes. It works because the
  systems at both ends are running on the Java platform, typically
! different pieces of a single larger application. Even then, it is
  most effective when both ends are using the same versions of all
  classes.
  
! In a system with shared code at both ends,
! objects can be trivially serialised and transmitted across a
! network connection. Exceptions are just another type of object, and
! so too can be sent over the wire. There is less need for an IDL, as Java
! interface declarations can perform much of the same role. And as the
! recipient is a remote object, state is automatic. One can even keep
! code synchronised by using a special class loader, one that fetches
! code from jointly accessible URLs.
  
  JAX-RPC tries to reuse many of the programming patterns of RMI. For
--- 392,410 ----
  Java RMI. Java's RMI system is a simple and effective mechanism for
  connecting Java classes running on different machines. It is an
! IDL-free system that relies on introspection to
! create proxy classes and to marshal data. It works because the
  systems at both ends are running on the Java platform, typically
! different pieces of a single larger application. Even then, it's
! implementation-first design means that it is brittle to change, and
  most effective when both ends are using the same versions of all
  classes.
  
! In a system with shared code at both ends, objects can be trivially serialised
! and transmitted across a network connection. Exceptions are just another type of
! object, and so too can be sent over the wire. There is less need for an IDL, as
! Java interface declarations can perform much of the same role. And as the
! recipient is a remote object, state is automatic. One can even keep code
! synchronised by using a special class loader, one that fetches code from jointly
! accessible URLs.
  
  JAX-RPC tries to reuse many of the programming patterns of RMI. For
***************
*** 421,426 ****
  was to enable loose coupling between the components of a distributed system.
  SOAP strove to overcome many of the failings of precursor technologies like
! CORBA and DCOM. These technologies work well over local area networks, and
! enable rich bidirectional communications, but are not completely cross
  platform\footnote{Admittedly for arguably political rather than technical
  reasons}, and ended up being used to produce distributed object systems that
--- 419,424 ----
  was to enable loose coupling between the components of a distributed system.
  SOAP strove to overcome many of the failings of precursor technologies like
! CORBA and DCOM. These technologies worked over local area networks, and
! enabled rich bidirectional communications, but were not cross
  platform\footnote{Admittedly for arguably political rather than technical
  reasons}, and ended up being used to produce distributed object systems that

Index: alpine.tex
===================================================================
RCS file: /cvsroot/smartfrog/core/extras/alpine/doc/jaxrpc/alpine.tex,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** alpine.tex	25 Apr 2005 22:29:05 -0000	1.16
--- alpine.tex	26 Apr 2005 13:52:52 -0000	1.17
***************
*** 3,7 ****
  
  We are in the preliminary stages of designing an alternative SOAP
! stack for Java, by the name of \emph{Alpine}.
  
  \subsection{Manifesto}
--- 3,11 ----
  
  We are in the preliminary stages of designing an alternative SOAP
! stack for Java, by the name of \emph{Alpine}. Its name is derived from the
! concept of \emph{Alpine-style mountaineering}, a higher-risk but nimble
! alternative to the government-supported porter-assisted \emph{Himalayan-style
! mountaineering}, which the current SOAP stacks remind us of.
!  
  
  \subsection{Manifesto}
***************
*** 31,35 ****
  headers. Developers will be expected to use XPath specifications to
  work with contents of the message; we are considering basing our
! design upon the ``XOM'' XML framework.  \cite{harold:xom}.
  
  This will not be a SOAP stack that attempts to make SOAP look like
--- 35,39 ----
  headers. Developers will be expected to use XPath specifications to
  work with contents of the message; we are considering basing our
! design upon the ``XOM'' XML framework \cite{harold:xom}.
  
  This will not be a SOAP stack that attempts to make SOAP look like
***************
*** 47,61 ****
  \begin{enumerate}
  
! \item Stay in the XML Space as much as possible
! \item Take advantage of as much leading edge infrastructure as we can
! \item Adopt the the handler chain pattern of Axis/JAX-RPC
! \item Target SOAP1.2 (POST) only, WS-I 1.1
! \item Document/literal only, not RPC/encoded
  \item Run server-side, client-side, and as an intermediary. 
  \item No support for JAX-RPC or JAX-M/SAAJ APIs.
  \item Configurable procedurally, through the Java Management API (JMX).
  \item Permit dynamic handler chain configuration during message processing.
! \item One supported parser %: Xerces
! \item Run on Java 1.5 and later. 
  
  \item No provision of side features such as a built in HTTP server, or
--- 51,66 ----
  \begin{enumerate}
  
! \item Stay in the XML Space as much as possible.
! \item Take advantage of as much leading edge infrastructure as we can.
! \item Adopt the the handler chain pattern of Axis/JAX-RPC.
! \item Target SOAP1.2 (POST) only, WS-I Basic Profile 1.1 \cite{spec:WSI-11}.
! \item Document/literal mssages only, not RPC/encoded.
! \item Support XSD and Relax NG schemas.
  \item Run server-side, client-side, and as an intermediary. 
  \item No support for JAX-RPC or JAX-M/SAAJ APIs.
  \item Configurable procedurally, through the Java Management API (JMX).
  \item Permit dynamic handler chain configuration during message processing.
! \item One supported parser. %: Xerces
! \item Run on Java 1.5 and later.
  
  \item No provision of side features such as a built in HTTP server, or
***************
*** 70,86 ****
  \label{alpine:validation}
  
! Although we are still unsure as to how complete our WSDL support will
! be, we note that document/literal SOAP messages can be validated
! simply by comparing the incoming messages to the XML Schema that
! describes them.
! 
! Mainstream SOAP stacks do not do this, usually for performance
! reasons. This means that the set of XML documents which an endpoint
! can receive is significantly larger than the set of XML documents
! which its XML schema considers valid. With no built-in validation,
! developers must either write both validation logic and corresponding
! tests themselves, or ignore the problem. Given that there is no
! warning that the problem occurs, we suspect that many developers
! remain unaware of the problem.
  
  Errors caused by the absence of logic to detect and reject illegal
--- 75,87 ----
  \label{alpine:validation}
  
! Although we are still unsure as to how complete our WSDL support will be, we
! note that document/literal SOAP messages can be validated simply by comparing
! the incoming messages to the XML Schema that describes them. Mainstream SOAP
! stacks do not do this, usually for performance reasons. This means that the set
! of XML documents which an endpoint can receive is significantly larger than the
! set of XML documents which its XML schema considers valid. With no built-in
! validation, developers must either write both validation logic and corresponding
! tests themselves, or ignore the problem. Given that there is no warning that the
! problem occurs, we suspect that many developers remain unaware of the problem.
  
  Errors caused by the absence of logic to detect and reject illegal
***************
*** 102,116 ****
  
  
! An open source project is written by its users, and so it
! is critical that as many users as possible can contribute to
! the implementation. JAX-RPC, by its very nature, places a firm divide
! between end users and developers. The split between XML in its internal API, and
! mapped object instances in the external API, creates
! a gulf between the implementation and the end user codebases. This creates
! an artificial barrier between being being a user and being a developer. 
! 
! With Alpine, we hope to avoid creating such a
! split, because the unified XML representation will run all 
! through the toolkit.
  
  
--- 103,114 ----
  
  
! An open source project is written by its users, and so it is critical that as
! many users as possible can contribute to the implementation. The split between
! XML in JAX-RPC's internal API, and mapped object instances in the external API,
! creates a gulf between the implementation and the end user codebases. This
! creates an artificial barrier between external and internal developers, to the
! detriment of open source implementations of the specifications. With Alpine, we
! hope to avoid creating such a split, because the unified XML representation will
! run all through the toolkit.
  
  
***************
*** 141,160 ****
  contracts by hand. Perhaps an alternate XML Schema language ---specifically
  RelaxNG--- will be needed to make XML type declarations easy
! \cite{spec:RelaxNG}. Similarly, WSDL2.0 may be an improvement
! on WSDL1.1 \cite{spec:WSDL2.0}. We do not yet have enough practial experience
! of WSDL2.0 to come to a valid conclusion.
  
! One of the flaws with using handwritten contracts to define SOAP stacks is
! that there no guarantee that any mainstream SOAP stack will be able to
! interoperate with a naively written XSD or WSDL contract. Unless all SOAP
! implementations adopt a pure-XML view of the world, the risk of interoperability
! problems remain. Clearly, the authors of service contracts will have to
! write their schemas and WSDL files with a clear understanding of which types and
! operations are supported in the client stacks expected to call the service. 
! It is for this reason that some SOAP developers advocate implementation-first
! development, on the grounds that may makes it possible for at least one SOAP
! stack to operate correctly with the service. This is essentially ignoring the
! cross-platform goal of SOAP, in order to avoid the interoperability problems
! that exist today. 
  
  If our Alpine project does not get adopted, then either the design was wrong,
--- 139,155 ----
  contracts by hand. Perhaps an alternate XML Schema language ---specifically
  RelaxNG--- will be needed to make XML type declarations easy
! \cite{spec:RelaxNG}. 
  
! One of the flaws with using handwritten contracts to define SOAP stacks is that
! there no guarantee that any mainstream SOAP stack will be able to interoperate
! with the contract. Unless all SOAP implementations adopt a pure-XML view of the
! world, the risk of interoperability problems remain. Clearly, the authors of
! service contracts will have to write their schemas and WSDL files with a clear
! understanding of which types and operations are supported in the client stacks
! expected to call the service. It is for this reason that some SOAP developers
! advocate implementation-first development, on the grounds that may makes it
! possible for at least one SOAP stack to operate correctly with the service. This
! is essentially ignoring the cross-platform goal of SOAP, in order to avoid the
! interoperability problems that exist today.
  
  If our Alpine project does not get adopted, then either the design was wrong,