[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-econtracts] Display/Presentation Agenda Item: Proposed Wording Second Draft
>... On the other hand, if this requirement is >accepted and inside the scope, then implementation of our final >specification(s) would need to reliably result in identical display between >the multiple parties to the contract. One of the implications is that any >interoperability testing that we might need before finalization would >necessarily have to include successful demonstration of this feature. I am concerned that this statement will lead us to a basic misunderstanding of what our work product is supposed to be. We are creating standards for a data stream that is exchanged between browsers; we're not creating applications! Our work fits into the matrix of datastream standards being defined by the W3C and others; if there is a feature that we functionally need, and it is supplied by the machinery of CSS2, then we should not, we must not, re-implement that feature. This is an operating assumption we must make, REGARDLESS of whether the feature is presently or correctly implemented by any of the browser manufacturers. In other words, we should ASSUME that implementations have available fully-conforming CSS2 browsers of HTML files. And, if necssary, we should ASSUME that implementations have available fully-conforming XSL-T transform engines. Think of the result if LegalXML re-specifies functionality already present in other W3C standards which one would reasonably expect implementers of our standard already to be using, or expecting to use, in their implementations: LegalXML would then be requiring implementers to implement functionality that is SUPPOSED to be in conforming browsers. That would yield a complete mess if every standards group did that! This is first time I have heard about "interoperability" testing. Interoperability is an APPLICATION concern -- this is not a concern of a standards group. All we're doing is specifying the format of a datastream, for crying out loud! Again, I am concerned that this statement surpasses by far the proper scope of this effort to standard the layout and format of a datastream. So, here's my suggestion for the Second Draft, if that's what people want, instead of the First Draft -- both the First and Second Drafts are functionally equivalent to me. [Second Draft amendedBy='JMc'] Yes or No: Subject to certain assumptions about a user's operating environment, the final eContracts specification will encompass and directly support the final, conclusive displayed version of a contract that is agreed by the parties. [/Second Draft]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]