[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 289 - draft text to describe the relationship XMLSchema and Spec
Hi Alex,
as shown in the given example, we already had a small scale asymmetry
before adding blockDefault.
I like your suggested text, let me propose a small change:
XML Schema offers supplementary normative XML syntax details, such as
details regarding extensibility of a WS-BPEL process definition, as
long as those XML syntax details do not violate explicit normative
descriptive text.
So the proposed text as a whole:
---------------------
Where there is disagreement between the separate XML schema files,
the XML schemas in the appendices, any pseudo-schema in the
descriptive text, and the normative descriptive text, the normative
descriptive text will take precedence over the separate XML Schema
files. The separate XML Schema files take precedence over any
pseudo-schema and over any XML schema included in the appendices.
XML Schema offers supplementary normative XML syntax details, such as
details regarding extensibility of a WS-BPEL process definition, as
long as those XML syntax details do not violate explicit normative
descriptive text.
XML Schemas only enforce a subset of constraints described in the
normative descriptive text. Hence, a WS-BPEL artifact, such as a
process definition, can be valid according to the XML Schemas only
but not valid according to the normative descriptive text. A summary
of the additional constraints can be found in Appendix B. Static
Analysis requirement summary.
---------------------
Best regards/Mit freundlichen Gr��en,
Thomas Schulze
Alex Yiu
<alex.yiu@oracle.
com> To
Thomas Schulze/Germany/IBM@IBMDE
10.08.2006 22:38 cc
Martin Chapman
<martin.chapman@oracle.com>,
wsbpeltc
<wsbpel@lists.oasis-open.org>, Alex
Yiu <alex.yiu@oracle.com>
Subject
Re: [wsbpel] Issue - 289 - draft
text to describe the relationship
XML Schema and Spec
Hi Thomas,
See inline ...
Thomas Schulze wrote:
Hi Alex,
in the second paragraph, maybe we can add a reference to the static
analysis table? In the appendix for the static analysis table,
there's a reference to the schema appendix, too.
[AYIU]:
I am open to the idea of having a reference to SA table.
For the first paragraph, regarding extensibility, there are forward
references in the spec to the schemas regarding the details, see
chapter
5.3:
"WS-BPEL supports extensibility by allowing namespace-qualified
attributes to appear on any WS-BPEL element and by allowing elements
from other namespaces to appear within WS-BPEL defined elements. This
is allowed in the XML Schema specifications for WS-BPEL."
Means, the schema is more specific regarding the modeled extension
points than the spec. One example is: Where in the sequence is the
extension element allowed to occur? The spec is silent about that,
the schemas are clarifying that. Additionally there's the
blockDefault="#all".
[AYIU]:
Well ... that was the reason all along that I was voicing the concern
against adding blockDefault="#all". The spec on this topic is silent, while
XSD are not. This small scale asymmetry does not look that good. ... :-)
... Well ... water is under the bridge ...
If one wants to be the spec text very formal about XML syntax, we should
use a bunch of XML Infoset term to describe the syntax (see WSDL 2.0 spec
text or majority of WS-* spec). Oblivously, we are not using those terms
unfortunately.
Maybe we can say something like "Regarding extensibility the schemas
are more detailed than the spec. In this case the schemas will take
precedence over the spec."?
[AYIU]:
IMHO, that is a bad practice to say one exceptional case where the schemas
take precedence over the spec, while all other cases spec take precedences
over schemas. Very confusing and difficult to enforce.
In JCP world, a javax package can provide extra normative details in
additional to the spec, as long as those details does not contradict the
spec text.
IMHO, I guess one of acceptable ways to add extra wordings to address your
concern is something like:
XML Schema offers supplementary normative XML syntax details, such as
where extension points are allowed in a WS-BPEL process definition,
as long as those XML syntax details do not violate explicit normative
descriptive text.
What do you think?
BTW, one thing to point out: XML Schema are not 100% portable enough across
different XML Schema Processor implementation, especially when it comes to
advanced part of the spec. In some cases, even Xerces-Java and Xerces-C++
(both are hosted under Apache and donated by the same company) behave
differently. ;-) ... Using XML Schema is THE authority for XML syntax is
not that bullet-proof either. In fact, I have personally faced an
Xerces-Java (of certain vrsion) implementation issue about <xsd:any>
handling.
Thanks!
Regards,
Alex Yiu
Best regards/Mit freundlichen Gr��en,
Thomas Schulze
Alex Yiu
<alex.yiu@oracle.
com>
To
Alex Yiu <alex.yiu@oracle.com>
09.08.2006 19:04
cc
wsbpeltc
<wsbpel@lists.oasis-open.org>,
Martin Chapman
<martin.chapman@oracle.com>
Subject
Re: [wsbpel] Issue - 289 -
draft
text to describe the
relationship
XML Schema and Spec
Hi all,
Here is an updated proposed text (with more input from Martin)
---------------------
Where there is disagreement between the separate XML schema files,
the
XML schemas in the appendices, any pseudo-schema in the descriptive
text, and the normative descriptive text, the normative descriptive
text
will take precedence over the separate XML Schema files. The separate
XML Schema files take precedence over any pseudo-schema and over any
XML
schema included in the appendices.
XML Schemas only enforce a subset of constraints described in the
normative descriptive text. Hence, a WS-BPEL artifact, such as a
process
definition, can be valid according to the XML Schemas only but not
valid
according to the normative descriptive text.
---------------------
Regards,
Alex Yiu
Alex Yiu wrote:
Hi all,
Here is the draft text to describe the relationship XML Schema
and Spec
(so far ...)
---------------------
XML Schemas are normative artifacts derived from the normative
descriptive text in the specification. XML Schemas only enforce
a
subset of constraints described in the normative descriptive
text.
Hence, a WS-BPEL artifact, such as a process definition, can be
valid
according to the XML Schemas but not valid by the normative
specification text. When there is a conflict between XML
schemas and
the normative descriptive text, the normative descriptive text
will
take precedence over XML Schemas.
---------------------
Regards,
Alex Yiu
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]