Merging DR106, DR086, DR087 to create DR500 and consistency of wording. Original DR500 split into new DR500 and DR501 to simplify meaning. Discussions prior to ballot, moved from draft to requirement following ballot. Merging DR001, DR030 and DR082 to DR085 to create DR501 and consistence of wording. Original DR500 split into new DR500 and DR501 to simplify meaning. Discussions prior to ballot, moved from draft to requirement following ballot. Clarification of XP's role in defining different message patterns - including multicast. Resulted in new wording for DR 502. Moved from draft to requirement following ballot Rewording of original support for different XML Idioms to match charter requirement for coordination with other XML WGs. Moved from draft to requirement following ballot. Simplification of original wording to emphasise lightweight specification. Moved from draft to requirement following ballot. Simplified wording. Moved from draft to requirement following ballot. Simplified wording and clarified the meaning of peer. Moved from draft to requirement following ballot. Corrected spelling. Changed "MUST" to "must". Lots of 'L' votes received on this one. XP must be suitable for widespread use across organizational boundaries in support of the application use cases supplied elsewhere in this document. This suitability requirement implies simplicity in the language of the XP specification, which itself describes a technology that is simple to understand and to implement correctly (see also DR301, DR301a, DR303). Although simplicity can only be measured in relative terms, the Working Group should ensure that the complexity of any solution produced is comparable to that of other current and widespread Web solutions. Changed "MUST" to "must". Changed "express" to "explicit". Reworded opening sentence to be less forceful. Removed "useful" from the second sentence. Since XP is intended to be a foundation protocol, its definition should remain simple and stable over time. Explicit use of modularity and layering in the resulting design will help assure longevity. Such a framework will allow subsequent extension of the design while leaving the foundation of the design intact. (DR300, DR302 and DR305 relate to stability). Some complaints that "modular, extensible...", etc. don't contribute to "simplicity"; the section covers both simplicity and stability, however we should reserve the right to move the requirement to another section. Also, at least one WG member dislikes the implication. SAX uses the term "interface consumer" to designate an entity calling methods on a SAX interface, and "interface implementer" to designate an entity which provides the services to the caller of the interface. These uses are exactly analogous to what we mean with regard to XP. "Application" above means "interface consumer", and "layered on top of (or bound to)" means "interface implementor. Does this wording seem clearer? I added some parenthetical phrases in the second section to try to correspond to section 7.1. In the above <resoultion> text I would prefer 'XP client' as the name for the a thing that sits ontop of/makes use of XP. From my layerist POV I refer to layer entities that impliment (or provide) the services at a layer boundary as providers (XP providers in this case) and things that make use of those services as clients (XP clients). This is probably moot because different folks are likely to have their own favorite terms for the these concepts. I agree that XP consumer isn't the best word but I don't like the term XP client either as there is a lot of client/server terminology. I prefer the term used in the glossary, namely "XP module". (absorbs old DRs: DR023, DR0053, DR088) The requirements that XP support the use of layering and be modular, extensible, and transport independent imply that there is an architectural design model behind XP. This architecture and the extensibility framework must be explicitly defined. (DR308 references modularity, DR302 and DR700 reference extensibility, DR502 and DR800 reference transport neutrality.) In this context, layering refers to both XP's support of XP modules (the layer(s) "above") as well as the capability of XP to define services required (the layer(s) "below") for implementation across a variety of underlying protocols. Changed "MUST" to "should". The XML protocol specifications should be clear and easy to understand. This clarity implies that considerable editorial effort will be required in the structuring of the narrative through both outline/overview and normative reference material. Changed "MUST" to "must". The XP specification must clearly identify conformance requirements in a way that enables the conformance of an implementation of the specification to be tested (see also the W3C Conformance requirements). Changed "MUST" to "must". Changed "modular extensibility" to "extensibility of vocabulary" (see notes below). Changed "human clients" to "human users". Issue has been raised that "without prior agreement" is out of scope, since this implies service discovery. As a counter argument, note that it's "decentralized extensibility" which can occur without prior agreement, and hopefully such functions can happen without service discovery. Agree that "modular" adds nothing in this context, but it's really the application vocabulary, including the envelope (??) which needs to be exstensible. Aligned the terms "evolve..." and "extend...". Changed "interfaces" to "user interfaces" since that's really the intent and is less problematic. The word "evolvability" still appears in the second section. My responded on this one referencing the WG Charter which I think places the 'without prior agreement' in-scope. http://lists.w3.org/Archives/Public/xml-dist-app/2000Nov/0106.html" I agree but I think the resolution keeps that term, so we should be all set. (Absorbs old DR's: DR107) The XML Protocol must support extensibility of vocabulary between communicating parties in a way that allows for decentralized extensibility without prior agreement. The WG must demonstrate through use cases that the solution supports decentralized extensibility in a modular and layered manner. To date the web has been enormously successful because it has enabled the creators of web services adapt the user interfaces they provide to human users of the web. A goal of XP is to achieve a similar levels of evolvability, extensibility and adaptability for interfaces between web services. Changed "MUST" to "should". Elided all but first sentence. Pretty controversial. Optional features do indeed make inter-operation harder. Perhaps we should just drop this one. (Absorbs old DRs: DR108) The XML protocol should be easy to understand, use, extend and implement. Changed "MUST" to "should". Changed "will" to "should". Altered the definition of "simple app". The XML protocol should facilitate the creation of simple applications. Simple applications are often characterized by message exchange patterns such as one-way (or event), and two-way (or synchronous) request response interactions. The specification should make such simple exchange applications as easy as possible to create and to use. Removed the parenthetical section, and made it a follow on sentence. (Absorbs old DRs: DR003) The XML protocol must provide facilities that encourage a common approach for providing features such as authentication, encryption,payment, reliable delivery, sessions and transactions. Such facilities might include optional standardized header and/or trailer elements. These facilities should encourage "best-practice" in implementing the required features. Changed "MUST/SHOULD" to "must". (Absorbs old DRs: DR090) The XML Protocol and applications of the XML Protocol must be easy to deploy - especially in systems already supporting XML technologies like XML namespaces and XML schemas. The ease with which XP applications can be deployed will be crucial to the success of XP. The design of the protocol architecture must be sensitive to the issues arising in the full spectrum of deployment environments ranging from resource constrained embedded devices (appliances) through high performance service engines. A very controversial item, could be dropped, but I think the point is good. Here's one last try. 309 I think remains problematic. It was one I introduced due to some dialog with Thomas Breuel (Xerox) who wanted to be able to do 'ack' (for want of a better expression) implementations. I tried to toughen it up a little, but its really about setting the minimal requirements with respect to namespace awareness and validating parsers in the context either of embedded systems and/or rapid (quick and dirty?) implementations. Personnally I wouldn't have a big problem if the community voted it out - I just wanted to respect the guy's concern and let the community discuss it. ... I guess this one has come a long way from the discussion thread that originally motivated the requirement which to some extend was about 'hack' implementation approaches and perhaps a little more cleanly about the use of 'basic' XML parsers, ie non-validating and non-namespace aware. May be a better expression of the requirement might go like: "In cases where the contract between entities is well known, for example in respect of the use of namespace qualifiers, it should be possible to implement XP using only basic XML parsing technique (non-validating and non-namespace aware parsers)." Of course we have introduced the concept of a contract here that is a little bit undefined! I agree that it is important but I think it is covered by #504. It might be better to just drop it. Let's see how it goes... In cases where the contract between entities is well known, the use of XP as a protocol to fulfill those application contracts should allow processing without requiring a complex XML application infrastructure provided the documents exchanged are well-formed and within the tenets of the XML Infoset. There is a suggestion that this one be split into 3 different pieces. Other 'D' comments are straightforward queries. The XP specification must define a mechanism or mechanisms that allow applications to submit application-specific content or information for delivery by XP. In forming the standard for the mechanisms, the XP specification may consider support for: - carrying application specific payloads inside the XP envelope, - referring to application specific payloads outside the XP envelope, - carrying nested XP envelopes as application specific data within the XP envelope, - referring to XP envelopes as application specific data outside the XP envelope To manage the mechanisms, the XP specification must define a set of directives which will unambiguously indicate to an XP processor which extensions are optional and which are mandatory so that it can: - process all of the extensions in an XP envelope or fail, - process a subset of the extensions in an XP envelope or fail. In both cases above, the XP processor must fail in a standard and predictable fashion. All the comments are 'L' comments. They mention an 'enveloping' spec in W3C (presumably packaging?) and coordination with ebXML. There is a suggestion that the requirement be split up into sub requirements, presumably to make it easier to read. The XP specification must define the concept of an envelope or outermost syntactical construct or structure within which all other syntactical elements of the message must be enclosed. The envelope must be described with XML Schema. The XP specification must also define a processing model that defines what it means to properly process an XP envelope or produce a fault. This processing model must be independent of any extensions carried within the envelope. The processing model must apply equally to intermediaries as well as ultimate destinations of a XP envelope. Much wailing and gnashing of teeth about the idea of 'comparing' messages. Alternative wording was provided in http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2000Nov/0077.html"/> which appeared to satisfy most of the comments. The XP specification must define the concept of protocol evolution and define a mechanism or mechanisms for identifying XP revisions. This mechanism or mechanisms must ensure that an XP processor, by simple inspection of an XP envelope, may determine whether or not the envelope is compatible with its processing ability. The specification must define the concepts of backwards compatible and backwards incompatible evolution. Furthermore, the XP envelope must support both optional and mandatory extensibility of protocols build using the XP envelope. A suggestion to split the requirement into two parts, most likely for the purpose of readability. Change "interaction model" to "message exchange protocol". Define "XP fault message" The XP specification must define a means to convey error information as a fault. The capability of XP carrying a fault message must not depend on any particular protocol binding. The XP specification must define a mechanism or mechanisms to allow the transfer of status information within an XP message without resort to use of XP fault messages or dependence on any particular interaction model. This requirement is somewhat general, and is subsumed by the more specific requirements for particular types of intermediaries. Requirement removed (redundant), introductory text remains. Some expression of concern that it isn't possible to identify sections of the message intended for the intermediary without reading the entire message. Changed from "reading or processing the entire message" to "processing the entire message". Also, slightly reworded to clarify. XML Protocol must also enable processing intermediaries to locate and process XP modules intended for them without processing the entire message. Slightly reworded to clarify. XML Protocol must not preclude the use of transport bindings that define transport intermediary roles such as store-and-forward, proxies and gateways. XML Protocol "core" cannot specify this mechanism, but should accommodate it as a use. Requirement to be reworked as a Use Case Slightly reworded to clarify, changed "components" to "modules" In the paragraph: "Targeting - XML Protocol must define mechanisms to enable identification of XP modules to be processed by a particular processing intermediary. Modules must be able to be targeted at one or more processing intermediaries.", I think that we might have to make some choices of what is supported directly by XP and what an XP module has to do. For example, is it possible to define a module that MUST be processed by *all* parties in a message path (I can't actually think of an example of a module that is mandatory for all parts of a message path). One way would be to say that the module has to define itself in such a way that part of the semantics is that it repeats itself so that it travels up the message path. In SOAP, the message path model allows the use of "actor" to identify one specific recipient of a module and nobody else can look at it. If there is no "actor" then it is allowed for any party to look at it but it can't take it out (that would be for something like "cache control" for example). I think this is a reasonable compromise as it allows for the module to define repeated behavior if it so desires without overly complicating the model. XML Protocol must define mechanisms that allow XP processors including intermediaries to identify modules which they are eligeble to process. XML Protocol "core" cannot specify this mechanism, but should accommodate it as a use. Requirement to be reworked as a Use Case Slightly reworded to clarify Reporting - XML Protocol must enable the generation of status and/or error messages by processing intermediaries, and enable propagation and proper identification of status and/or error messages through processing intermediaries. XML Protocol "core" cannot specify this mechanism, but should accommodate it as a use. Requirement to be reworked as a Use Case XML Protocol "core" cannot specify this mechanism, but should accommodate it as a use. Requirement to be reworked as a Use Case none request for clarification - leave as-is none request for clarification - leave as-is none leave as is none leave as is none leave as is All of the comments are 'L' votes. The XP specification must not mandate any dependency on specific features or mechanisms provided by a particular transport protocol beyond the basic requirement that the transport protocol must have the ability to deliver the XP envelope as a whole unit. This requirement does not preclude a mapping or binding to a transport protocol taking advantages of such features. It is intended to ensure that the basic XP specification will be transport neutral. There is a minor concern that having XP not depend on protocol features will lead to duplication of effort. Editorial opinion is that this is a misunderstanding of what 'transport neutral' means. There is no requirement to re-invent the wheel. There is some concern about what "information loss from the message" means. The XP specification must consider the scenario where an XP message may be routed over possibly many different transport or application protocols as it moves between intermediaries on the message path. This requirement implies it must be possible to apply many transport or application protocol bindings to the XP message without information loss from the XP message content. This requirement is felt to be inadequately specified. What this means is that either there be a fuller and more fleshed out requirement which covers the security domain entirely or that this requirement should not be here. The XML Protocol binding mechanism must not preclude the possibility of constructing bindings to protocols that provide a security mechanism. Typical examples of such protocols are SSL providing a secure channel, and S/MIME which provides a secure wrapper. It should be possible to specify XP bindings for such security protocols. Almost everybody hated this one! This is the 'limit to UTF-8' requirement. This has been degraded from a requirement: The XP WG recognizes that the issue of codeset diversity is a complex one and will defer any decision on codesets for XP until consultation with the Internationalisation WG has clarified the issue. Some concern that having a single normative binding may cause people to think that XP is tied to that particular protocol. Unfortunately, we only have time to work on one normative binding. Others should emerge over time. The wording about the browser subset of HTTP has been removed - this was the cause of many D votes. The XP specification must provide a normative description of the default binding of XP to HTTP. This binding, while normative, is not to be exclusive. Any protocol binding to HTTP must respect the semantics of HTTP and should demonstrate that it can co-exist with existing HTTP/1.0 and HTTP/1.1 applications. |--> |--> 1) Reworded first bullet as per http://lists.w3.org/Archives/Public/xml-dist-app/2000Nov/0147.html. 2) Referred to "applications and services" in places where we were previously referring to RPC "applications" 3) Reintroduced the bullet item related to matching responses to requests as per http://lists.w3.org/Archives/Public/xml-dist-app/2000Nov/0147.html. I agree - it is redundant, but especially important in the context of RPC. 4) Switched to using MUST instead of WILL. New wording: The XML Protocol must contain a convention for representing calls and replies between RPC (Remote Procedure Call) applications and services. The conventions must include the following: 1.Complete and unique identification, by means of URI syntax, of the program, service or object and procedure or method to be called." 2. Enable support for matching response messages to request messages for cases in which matching is not provided by the underlying protocol binding. 3. The ability to specify the parameters to a call in a request message and the results of a call in a reply messages. 4. Provisions for specifying errors in a reply message (see also 703) Where possible, an attempt will be made to leverage any related work done by the IETF. |--> |--> |--> |--> |--> |--> |--> |--> The bulk of discussion related to this DR revolves around the sentence "There will be straightforward mappings of the data types used to a wide variety of widely deployed programming languages and object systems". Some believe that this requirement should fall into the Data Representation section, others that the notion of language bindings is out of scope. The most complete description of the confusion related to this requirement is in Noah Mendelsohn's posting () and the next several messages in the same thread. I've changed the wording of the line to eliminate some of the confusion regarding whether the XP group will create language bindings. I may consider eliminating the setence altogether, pending further discussion. I believe it represents a fairly fundamental question related to RPC invocation - is the goal of RPC in XP merely to just support the abstract notion of invoking a service or is the goal to allow for the convenience of a more concrete and automatic mapping or proxying of the service to a call-side construct. New wording: The RPC conventions within the XML Protocol should use the Data Representation model discussed in section 3.5 to represent parameters to a call in the request message and results of the call in the reply message. It must be convenient to create straightforward mappings of the data types to a wide variety of widely deployed programming languages and object systems. |--> |--> |--> |--> There was some concern that mentioning "custom encodings" could lead to problems with interoperability. This is balanced out by the need for an extensibility mechanism. Many of the comments asked for removal of the sentence relating to automatic binding - this has been done. The editor of the Data Representation section should also look at this requirement in the context of the others in the RPC Conventions section and see if it should be incorporated into his section. The posting http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2000Nov/0262.html contains a suggestion from me regarding missing Data Representation requirements. New wording: The XML Protocol should allow applications to include custom encodings for data types used for parameters and results in RPC messages. |--> |--> |--> The wording for this requirement has always been ambiguous - I had hoped to get feedback with some wordsmithing. However, many of the "D" ballots contained requests to eliminate this requirement, some citing redundancy with parts of DR201, others questioning the use of the word "guarantee". This DR has been dropped.