[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [wsbpel] Issue - 295
Resending Thomas's email with the issue # in the subject.
I believe
that Thomas has identified all of the issues where this applies:
-
<variable name="...">
- <forEach counterName="...">
-
<onEvent variable="...">
- <onEvent>'s <fromPart
toVariable="...">
- <catch faultVariable="...">
Would we want to update all of pseudo schema examples to use the new type name or leave them as NCName?
As for the question about defining a
variable's type in <fromPart>'s implicit var declaration, I believe we
state that the type comes from the message part's type
declaration.
-----Original Message-----
From: Thomas
Schulze [mailto:ThomasSchulze@de.ibm.com]
Sent:
Monday, June 05, 2006 4:11 AM
To: Mark Ford
Cc: 'Alex Yiu';
'wsbpeltc'
Subject: RE: [wsbpel] RE: NCName restriction to avoid
"."
+1 to the idea catching this by the schema validation.
Isn't
this constrain only needed for those places where new variables are declared?
That should be <variable name="...">, <forEach counterName="...">,
<onEvent variable="..."> and the <fromPart toVariable="..."> version
of <onEvent> and <catch faultVariable="...">.
All other cases
are variable references. Not sure if we really need it there.
Btw.
doesn't the <fromPart toVariable="..."> variant of <onEvent> require
the variable's type defined (attributes messageType, element and
type)?
Best regards/Mit freundlichen
Grüßen,
Thomas
Schulze
"Mark
Ford"
<mark.ford@active
-endpoints.com>
To
"'Alex Yiu'"
<alex.yiu@oracle.com>
05.06.2006
01:35
cc
"'wsbpeltc'"
<wsbpel@lists.oasis-open.org>
Subject
RE: [wsbpel] RE: NCName
restriction
to avoid
"."
Yes.
Basically, anywhere that we're referring to a variable the type should be
"BPELVariableName" instead of "NCName". Of course I'll leave the actual
selection of the name to the schema powers at be but you get the
idea.
The only downside to this is that we need to add a little more text
to the current spec to define what this type is since it will appear in our
pseudo schema examples. This may impact readability a little but it goes a long
way in making the restriction explicit. If I were reading the spec for the first
time and I saw "BPELVariableName" for the data type I would naturally assume
that there was some restriction in play and then go and find the definition of
this type. As it is now, NCName appears in multiple places without any kind of
qualifier to indicate that it's a restricted NCName.
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent:
Sunday, June 04, 2006 7:26 PM
To: Mark Ford
Cc: 'wsbpeltc'; Alex
Yiu
Subject: Re: [wsbpel] RE: NCName restriction to avoid
"."
Mark,
Do we want to apply the same restriction to variable
attribute of <from> and <to> spec
also?
Thanks!
Regards,
Alex Yiu
Mark Ford
wrote:
+1 from me
;)
This would also apply to the implicit
variables created by a
<fromPart> nested
within an onEvent.
I'll open an issue on
this.
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Sunday, June 04, 2006 5:38 PM
To:
wsbpeltc
Cc: Mark Ford; Alex
Yiu
Subject: NCName restriction to avoid "."
(was: [Fwd: BPEL Schema
question])
Hi
guys,
Mark has the following suggestion to
use the data type other than
NCName to
restrict the "." usage in variable names.
I am OK with it.
Thought?
Thanks!
Regards,
Alex
Yiu
-------- Original Message
--------
Subject: BPEL Schema
question
Date: Sun, 4 Jun 2006 13:27:35
-0400
From: Mark Ford
<mark.ford@active-endpoints.com>
To: 'Alex Yiu'
<alex.yiu@oracle.com>
Hi Alex,
What do you think about
changing the data type of a variable's name
to
be a restriction of NCName to disallow the "." as described
in
Section 8.1? The dot is a legal value for
NCNames but disallowed for
Xpath binding
purposes of message variables.
This
also applies to the name of the counter attribute on
a
<forEach>.
I'd prefer to catch
these types of errors with the XSD as opposed
to
having to write code to catch them during
static analysis.
Thanks.
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that generates this
mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]