Hi, Paul and all others,
[Note: I have exchanged a number of emails with Paul in private
already. I would
like to share our conversation to the general public.]
For items (1), (4), (5), (8): those are non-normative editorial
changes. I have just made those into the latest round of XSD editing
work.
For item (2):
I have confirmed with our XSD team at Oracle. [Millions thanks to
their help and advice.]
<xsd:anyAttribute namespace="##other" .../> actually requires a
namespace-qualified attribute. Therefore, its semantics fits our
expectation.
See section 3.10.2:
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#declare-openness
------------------------------------------------------
- ##other
- a pair of not and the ·actual value· of the
targetNamespace [attribute] of the <schema> ancestor
element information item if present, otherwise ·absent·.
------------------------------------------------------
AND, Section 3.10.4: (Validation 2.* for "##other")
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#section-Wildcard-Validation-Rules
------------------------------------------------------
Validation Rule: Wildcard allows Namespace Name
For a value which is either a namespace name
or ·absent·
to be ·valid·
with respect to a wildcard constraint (the
value of a {namespace constraint}) one of the
following must be true:
1 The constraint must be any.
2 All of the following must be true:
2.1 The constraint is a pair of not and a
namespace name or
·absent·
( [Definition:] call this
the namespace test).
3 The constraint is a set, and the value is
identical to one of the members of the set.
For item (3):
This is a good catch and a bug that we need to fix. I would agree with
your suggestion. However, it will cause a minor normative change in the
spec. We can piggy-back that with Issue 103, if you want. Or else, you
may want to file a separate bug issue.
For item (7):
I agree with your findings. There is a bug + lack of parallel
constructions ("bpel:imports") issue. The same bug was discovered by
Dieter Koenig also. I have fixed maxOccurs bug. Regarding to the
parallel construction, since it will cause a minor normative changes, I
would suggest you to file a bug issue against that.
For item (9):
Originally, I also thought that was a good idea. However, after I
played with it, I discovered that introduces a non-determinism error at
<choice>.
W3C-XSV reported this error:
-------------------------
Invalid: non-deterministic content model for type tEventHandlers:
{http://schemas.xmlsoap.org/ws/2004/03/business-process/}:onAlarm/{http://schemas.xmlsoap.org/ws/2004/03/business-process/}:onAlarm
-------------------------
For item (10):
There is a real reason to have multiple documentation. Please note that
the documentation is i18N ready with xml:lang attribute. Users of an international BPEL
project may need to document the same BPEL with different languages.
And, again we borrow this design pattern from XML Schema itself.
For (11):
I am comfortable with your suggestion in general. Again, since it
contains normative changes to the spec for parallel construction, I
would suggest you to file a bug issue to track this down.
For (12), what are other legal values in your mind? This will qualify a
normative changes again.
For (13), I feel comfortable with your suggestion. This will qualify
another normative change. Again, please file a bug issue against that.
Thanks!
Regards,
Alex Yiu
Paul R Brown wrote:
Hi, Prasad / Alex --
Sept 02, 2004 version of the WS-BPEL main
schema.
For any fellow emacs/nxml-mode junkies, I have a version of the schema
in RNC form; it is here[1] for anyone who wants it. (There is also a
version[2] of BPEL4WS 1.1 (March 2003).) I have (probably) made some
mistakes with the transcription, but there are some niceties with the
RNC versions, e.g., enforcement of different from-spec's.
In the course of performing the transcription, I came up with a few
items/comments; I'll request an advance indulgence for anything that
constitutes overmuch language-lawyering.
1) I agree with Ian's earlier comments about explicitly stating mixed
content when present (whether or not the minutiae in the XML schema
specification(s) require it), since it's clearer to someone (God
forbid) reading the schema.
2) The use of the xs:anyAttribute extensibility mechanism seems a
little silly from a practical perspective... The schema states that
any attributes outside of xmlns:bpel are permitted, but since the
attributes in the schema are all unqualified, this doesn't really meet
the goal of excluding the namespace that the schema addresses. This
should really be "any namespace-qualified attribute in a non-default
namespace other than the xmlns:bpel namespace", but this is not
possible in XML schema[3]. Nonetheless, it could be specified in the
documentation for the schema or other annotation.
3) The literal form of the from-spec clashes with the extensibility
elements. (Is the schema-legal bpel:documentation element part of the
assignment?) A non-extensible bpel:literal child would correct this
asymmetry and make the literal from-spec more explicit:
from.literal =
element bpel:from {
extensibility,
element bpel:literal {
( text* & OTHER* )
}
}
4) Having the tTo type be non-extensible (documentation and ##other
children) seems asymmetric. (If I can document a bpel:link, I should
be able to document a bpel:to...)
5) The bpel:service-ref child of the bpel:from is not technically
allowed by the literal form of the tFrom type (because the service-ref
element is in the xmlns:bpel namespace). This should probably be a
sixth form of the from-spec and explicitly called-out in the schema.
In RNC, this would be:
from.service-ref =
element bpel:from {
extensibility,
element bpel:service-ref {
attribute reference-scheme { xsd:anyURI },
OTHER+
}
}
6) If I may nitpick, the hyphenated names for bpel:service-ref and
reference-scheme are at odds with the camelCase names used elsewhere in
the schema.
7) The schema specifies that bpel:import appears zero or one times;
this should be zero or more. (The default value[4] of maxOccurs is 1,
so it should be specified to be "unbounded" in this case.) Parallel
construction with other items (variables, events/alarms,
catch/catchAll, etc.) would suggestion that it be wrapped in a
bpel:imports element.
8) It is possible to express the grammar for (for|until)?repeatEvery in
XML schema without introducing non-determinism, so I'll propose the
following alternative to what's in the schema:
<complexType name="tOnAlarm">
<complexContent>
<extension base="bpws:tExtensibleElements">
<sequence>
<choice>
<element name="for" type="bpws:tDuration-expr"/>
<element name="until" type="bpws:tDeadline-expr"/>
</choice>
<element name="repeatEvery" type="bpws:tDuration-expr"
minOccurs="0"/>
<group ref="bpws:activity"/>
</sequence>
</extension>
</complexContent>
</complexType>
The same holds for the bpel:wait activity:
<complexType name="tWait">
<complexContent>
<extension base="bpws:tActivity">
<choice>
<element name="for" type="bpws:tDuration-expr"/>
<element name="until" type="bpws:tDeadline-expr"/>
</choice>
</extension>
</complexContent>
</complexType>
9) I'll propose a change to the grammar for tEventHandlers that is
((bpel:onEvent+ bpel:onAlarm*)|bpel:onAlarm+) instead of (bpel:onEvent*
bpel:onAlarm*):
<complexType name="tEventHandlers">
<complexContent>
<extension base="bpws:tExtensibleElements">
<choice>
<sequence>
<element name="onEvent" type="bpws:tOnMessage"
minOccurs="1" maxOccurs="unbounded"/>
<element name="onAlarm" type="bpws:tOnAlarm"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<element name="onAlarm" type="bpws:tOnAlarm" minOccurs="1"
maxOccurs="unbounded"/>
</choice>
</extension>
</complexContent>
</complexType>
10) IMHO, it doesn't make much sense to me to have multiple
bpel:documentation elements head-to-tail at the start, so maxOccurs="1"
makes more sense.
11) Either no bpel:faultHandlers element on bpel:process and bpel:scope
or a bpel:faultHandlers child of bpel:invoke would be parallel
construction.
12) The definition of the importedURI seems overly restrictive, as the
two values are not the only two legal values.
13) Allowing the use of <xs:any processContents="lax" /> within
bpel:documentation allows a bpel:documentation element to comment out
portions of a process, but that's the only reason that I can think of
to use <any processContents="lax" /> insetad of <any
namespace="##other" processContents="lax" />
If it's useful, I'm willing to make these edits to the schema and
circulate it.
-- Paul
[1] http://blogs.fivesight.com/pbblog/wp-content/bpel_20040902.rnc
[2] http://blogs.fivesight.com/pbblog/wp-content/bpel_1_1.rnc
[3]
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#declare-openness
[4] http://www.w3.org/TR/xmlschema-0/#OccurrenceConstraints
To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
|