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>