[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Issue 56: Specification / Schema conflict resolution
Dale, There are a few intertwined issues being discussed: 1. Dispute Resolution We need a process to resolve disputes, whether it's spec/schema related or an interpretation issue or other. 2. Method for communicating/issuing corrections (spec, schema and interpretations) 3. Distribution of the "normative" schema. Regarding 1: During spec development I believe it's the TC's responsibility to resolve disputes using the standard consensus process. IMO, the TC should investigate issues and provide a resolution. AFTER a spec is released another process (hopefully one is defined by OASIS), is used to resolve issues with the spec and other related documents. Does OASIS already have such a process (Ian)? I suspect they do. Regarding 2: I'm assuming that OASIS standard processes dictate how specs and other related documents are distributed, including errata. We should consult the OASIS process for this. Regarding 3: I suspect people will cache schemas locally (I know I am) and individuals should be responsible for updating these schemas, after receiving notification of corrections via the process used in 2. Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com <http://www.systrends.com> Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714 -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Monday, February 18, 2002 12:05 PM To: dick@systrends.com; Christopher Ferris; David Fischer Cc: Doug Bunting; ebXML Subject: RE: [ebxml-msg] Issue 56: Specification / Schema conflict resolution Dick, I have trouble with the question being posed about deciding on a policy to deal with what to do when there is a discrepancy between the specification and the schema. (Let's assume both are normative.) The spec can be wrong. The schema can be wrong. Why do we need to decide that we will always regard one source as "correct"? In the next version, maybe the words will need to be rewritten, maybe the schema will need changes. The real problem, to me, is what to do when a discrepancy is discovered, and it causes an interoperability problem. What is our recommended workaround for vendors and users until _either_ the spec is changed or the schema changed, and the discrepancy is removed. I would say that it is easier to implement a workaround for a problem of this nature either by ignoring the text (because it is wrong) or issuing a schema update (because it was wrong). Therefore, in either case, it boils down to how we should do schema updates. (If both were wrong, still fix the schema first please, and the text later.) And I think none of this should be used as an excuse not to fix discrepancies that are now known. Dale -----Original Message----- From: Dick Brooks [mailto:dick@systrends.com] Sent: Monday, February 18, 2002 10:15 AM To: Christopher Ferris; David Fischer Cc: Doug Bunting; ebXML Subject: RE: [ebxml-msg] Issue 56: Specification / Schema conflict resolution Chris, I agree, the schema needs to be normative. However, I believe the specification should take precedence when there are differences between the schema and the spec. Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com <http://www.systrends.com> Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714 -----Original Message----- From: Christopher Ferris [mailto:chris.ferris@sun.com] Sent: Monday, February 18, 2002 6:30 AM To: David Fischer Cc: Doug Bunting; dick@systrends.com; ebXML Subject: Re: [ebxml-msg] Issue 56: Specification / Schema conflict resolution David, With all due respect, the XML schema in v1.0 was normative. Before the decision was made to go with SOAP 1.1 as the underlying protocol, we did have a non-normative XML Schema version of the normative DTD, but the adoption of SOAP changed all of that and the XML schema for our ebXML SOAP extension elements became, of necessity, normative (and we had to drop the DTD because SOAP doesn't support DTDs). The schema needs to be normative IMO. Cheers, Chris David Fischer wrote: > Doug, > > No, we don't have to ratify both the text and the schema. The v1.0 group > validated only the text with an EXAMPLE schema in an appendix. I suggest, we > should follow that path. All we have to ratify is the text. > > I am looking for, but have not yet found, an example of a standard in which code > takes precedent over the words. Is there such a thing? All the ones I have > looked at so far are specifically the reverse. > > Perhaps we should pull the schema out of the spec and have it as a separate, > non-normative document? > > Regards, > > David. > > -----Original Message----- > From: Doug Bunting [mailto:dougb62@yahoo.com] > Sent: Sunday, February 17, 2002 1:32 AM > To: dick@systrends.com; ebXML > Subject: Re: [ebxml-msg] Issue 56: Specification / Schema conflict > resolution > > > Dick, > > Sorry to return to an issue after it's a little cold. > > I agree completely where the document and specification overlap they should > agree. However, the schema contains information not in the document and > visa versa. In addition, we're not going to be perfect. Our comments on > the Description element and the SequenceNumber datatype shouldn't be taken > to mean we've found every place the two things don't match. > > I don't agree the document should win simply because we discussed it more in > our group. As a group, we should be publishing a schema and a document > which form a unified answer to the question of "how do I send an ebXML > document?" We must ratify both. We must also understand how the schema > will be used and recognise that use in our document. > > While some XML parsers may cache copies of the schema, what we publish at > the location described in the document is a normative part of our overall > protocol description. The interesting thing is how a receiving application > could possibly override the behaviour of the XML parser to meet the terms of > the document. Since the SOAP processor and it's embedded XML parser (in a > layered approach using a generic SOAP processor) or an XML parser alone > (feeding information to a somehow mixed MSH and SOAP processor) will process > the document before the code of an ebXML Messaging handler, the message > should be validated against the schema before the MSH starts doing its work. > Certainly, code could be written to send a message that won't validate > against the schema but the receiver will have a hard time using code to get > past the validation error. > > I generally see the document as describing (referencing and explaining) the > normative information in the schema for the areas the two things overlap. > The layers in an MSH implementation sitting on top of an XML parser (and, > likely, a SOAP processor) are what developers can directly control. They > have to take the schema as a given. That's why it "wins" if there should > ever be a conflict now or in the future. > > thanx, > doug > > ----- Original Message ----- > From: "Dick Brooks" <dick@systrends.com> > To: "Doug Bunting" <dougb62@yahoo.com>; "ebXML" > <ebxml-msg@lists.oasis-open.org> > Sent: Tuesday, February 12, 2002 3:58 PM > Subject: RE: [ebxml-msg] Issue 56: Specification / Schema conflict > resolution > > > Doug, > > I believe the specifications, which contain the consensus agreements of the > workgroup, should take precedence over the schema. > > IMO, the schema should "implement" the spec without modification. If the > schema is "wrong" an "errata" for the schema should be issued. > > Dick Brooks > Systrends, Inc > 7855 South River Parkway, Suite 111 > Tempe, Arizona 85284 > Web: www.systrends.com <http://www.systrends.com> > Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714 > > > -----Original Message----- > From: Doug Bunting [mailto:dougb62@yahoo.com] > Sent: Tuesday, February 12, 2002 5:38 PM > To: ebXML > Subject: [ebxml-msg] Issue 56: Specification / Schema conflict > resolution > > > We need to choose a "winner" when (as will inevitably happen) the words of > the > specification disagree with the separate schema instance. My suggestions > make > clear choices rather than leaving things open. Further, we need to choose a > winner our programs can implement without conflicting with a normative > deliverable from our group. We provide a schema that arriving messages will > be checked against before the application even hears about it. Therefore, > it > will win and that must be reflected in our documentation. > > thanx, > doug > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC