OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[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]