Hi Danny,
IMO this limitation is for the declarations only. If all declarations
are
ok, a reference, if it is valid, can't reference a variable name with a
'.'
in it. Static analysis have to check anyway if a referenced variable
name
is declared in a parent scope, and will flag this reference as an
error, if
it's not. So why schould the schema generate an additional error for
that
invalid reference?
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Danny van
der
Rijn
<dannyv@tibco.com To
> Mark
Ford
<mark.ford@active-endpoints.com>
07.06.2006 01:14
cc
wsbpeltc
<wsbpel@lists.oasis-open.org>, Alex
Yiu <alex.yiu@oracle.com>,
Thomas
Schulze/Germany/IBM@IBMDE
Subject
Re: [wsbpel] Issue -
295
I can't see why we *wouldn't* want to use the new type in references.
Mark Ford wrote:
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