OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue - 92.7 - proposal to vote


+1

I agree with you Yaron, which prompted me to bring up using
xsi:schemaLocation in last weeks meeting.  First it's already there and we
don't have to invent something.  Secondly XML parsers already know how to
deal with it.  Adding this mechanism could force implementations to parse
the BPEL twice before they can determine if it is valid.

I suggested that if an attribute were added it should be along the lines of
an overviewURL (like UDDI does in its tModel), which points to additional
information about the extension.  But doing nothing is good too.

- Chris

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Tuesday, July 19, 2005 6:37 PM
To: Alex Yiu
Cc: Prasad Yendluri; wsbpeltc
Subject: Re: [wsbpel] Issue - 92.7 - proposal to vote

As much as I don't like xsi:SchemaLocation I equally don't like the idea 
of us inventing yet another schema pointing mechanism. I think doing 
nothing is the least dangerous option here.

	Yaron

Alex Yiu wrote:
> 
> 
> Hi,
> 
> I tend to see 92.7 is the last step to complete the semantics of
> <extension> (a new construct added in the last couple of months).  It
> will make <extension> symmetrical to <bpel:import> as Danny mentioned in
> the last conf call.
> 
> For RDDL concern / question, if we accept it, the same should be applied
> to Issue 88. And, you did not raise that concern in Issue 88?
> 
> Applying two schema languages simultaneously to one namespace is
> something relatively undefined  ... (e.g. who will resolve conflict
> between those two schemas? E.g. XML Schema has the concept of local
> element declaration, while DTD does not have such a concept.)
> 
> Without adding schemaLocation attribute to <extension>, the other only
> standardized mechanism to achieve similar effect will be adding
> xsi:schemaLocation to BPEL source code.  ... Yaron ... I am a bit
> surprised / puzzled that you would rather picking that path, given that
> you are not an XSD-lover. :-)
> 
> 
> Thanks!
> 
> 
> Regards,
> Alex Yiu
> 
> 
> Yaron Y. Goland wrote:
> 
>  > I believe this group has reached a point in its development where the
>  > bar for accepting normative changes to the spec needs to be raised. At
>  > this point we should only be accepting normative changes that fix
>  > serious bugs in the spec or specify previously agreed upon must-have
>  > features. I do not believe that 92.7 passes either of these tests.
>  >
>  > Furthermore, as Prasad's mail indicates, there are still significant
>  > open questions in the community about the best way to point at
>  > schemas. For example, the proposed 92.7 design suffers from issues
>  > around how do you point to two schemas in two languages that both
>  > describe the desired syntax?
>  >
>  > I don't think the BPEL TC should take it upon itself to resolve these
>  > issues in general and I especially don't think we should be taking
>  > these issues at this late date in our standards process.
>  >
>  > I therefore propose that we close issue 92.7 with no action.
>  >
>  >         Yaron
>  >
>  > Prasad Yendluri wrote:
>  >
>  >> Hi Alex,
>  >>
>  >> I am suggesting this as an alternate mechanism to use of
>  >> @SchemaLocation and @SchemaLanuguage.
>  >> Given both of the above @'s are optional once can chose not to
>  >> specify these and supply a RDDL doc at the location the namespace URI
>  >> resolves to.
>  >> In addition I think we should consider doing it for own own BPEL
>  >> namespace.
>  >>
>  >> Regards, Prasad
>  >>
>  >> Alex Yiu wrote:
>  >>
>  >>>
>  >>> Hi,
>  >>>
>  >>> Interesting suggestion ...
>  >>>
>  >>> Some clarification questions:
>  >>>
>  >>>     * Are you suggesting we must always use RDDL mechanism to resolve
>  >>>       resources? Or, you are suggesting RDDL as a supplementary
>  >>> mechanism in
>  >>>       addition to the simple Location URI mechanism?
>  >>>     * Do you want to apply RDDL to <bpel:import>? (A new issue? or
>  >>> Issue 88?)     * Do we want to add RDDL as a normative reference to
>  >>> the BPEL spec? and
>  >>>       which standard spec has added RDDL as a normative reference
>  >>> for its
>  >>>       resource look up so far?
>  >>>
>  >>> My current gut feeling is: if we want to use RDDL, we should use it
>  >>> as a supplementary way. If we want to use RDDL, we should use it
>  >>> consistently in all "location-URI" related BPEL construct. (e.g.
>  >>> bpel:import). And, I am worrying whether we run too ahead of other
>  >>> related specs (e.g. WSDL and XSD) in terms of RDDL support.
>  >>>
>  >>>
>  >>> Thanks.
>  >>>
>  >>>
>  >>> Regards,
>  >>> Alex Yiu
>  >>>
>  >>>
>  >>> Prasad Yendluri wrote:
>  >>>
>  >>>> The recent trend on this seems to be towards having the (extension)
>  >>>> namespace URI resolve to a (RDDL) document that embeds the URL for
>  >>>> the associated schema (if any) in addition to describing the
>  >>>> extension formally.  WS-Addressing had recently done this for its
>  >>>> own namespace (see attached) and XML schema had also done this
>  >>>> http://www.w3.org/2001/XMLSchema.
>  >>>>
>  >>>> I guess the proposal is to make the schemaLocation an optional @
>  >>>> but, using the RDDL approach confines things to one URI and any
>  >>>> changes are reflected in the document that the URI resolves to
>  >>>> rather than the BPEL definition having to update multiple URIs
>  >>>> associated with the extension
>  >>>>
>  >>>> Regards, Prasad
>  >>>>
>  >>>> Alex Yiu wrote:
>  >>>>
>  >>>>>
>  >>>>> Hi all,
>  >>>>>
>  >>>>> Here is the proposal to vote for Issue 92.7. (attached HTML file).
>  >>>>> Thanks!
>  >>>>>
>  >>>>> Regards,
>  >>>>> Alex Yiu
>  >>>>>
>  >>>>> 
>
----------------------------------------------------------------------------
---- 
> 
>  >>>>>
>  >>>>>
>  >>>>>
>  >>>>>       Proposal for Issue 92.7
>  >>>>>
>  >>>>> Last modified: Jun 27, 2005 - 7 pm PDT
>  >>>>>
>  >>>>> Summary:
>  >>>>> Adding optional schemaLocation and schemaLanguage attribues to
>  >>>>> <extension> and an optional schemaLanguage attribute to
<extensions>
>  >>>>>
>  >>>>> -------------------------
>  >>>>> <extensions schemaLanguage="URI"?>
>  >>>>>     <extension namespace="URI" mustUnderstand="yes|no"
>  >>>>>                schemaLocation="URI"? schemaLanguage="URI"? />*
>  >>>>> </extensions>
>  >>>>> -------------------------
>  >>>>>
>  >>>>> Rationale:
>  >>>>> To enable a portable syntax validation mechanism for extensions
>  >>>>> used in WS-BPEL. Particularly, enabling de-coupling and
>  >>>>> interoperability between BPEL designer tools and BPEL engine in
>  >>>>> the context of BPEL extensions.
>  >>>>>
>  >>>>> Details:
>  >>>>>
>  >>>>> The optional "schemaLocation" refers to the location of a schema
>  >>>>> for XML which provides extra syntax validation information for
>  >>>>> extension element and attributes used in WS-BPEL. The usage of the
>  >>>>> "schemaLocation" is optional. That means, when the attribute can
>  >>>>> be omitted, WS-BPEL processor will NOT do any syntax validation,
>  >>>>> if it does not understand that namespace (i.e. not a well-known
>  >>>>> namespace to a particular implementation).
>  >>>>>
>  >>>>> If the extension attributes and elements are invalid according to
>  >>>>> the schema specified by the "schemaLocation", the WS-BPEL
>  >>>>> processor MUST detect this condition during static analysis and
>  >>>>> reject the process defintion.
>  >>>>>
>  >>>>> WS-BPEL specification does not mandate a particular schema
>  >>>>> language for XML to be used for extension syntax validation. The
>  >>>>> choices of schema languages include and are not limited to: W3C
>  >>>>> XML Schema (http://www.w3.org/2001/XMLSchema). The schema language
>  >>>>> used by a particular extension is indicated by the
>  >>>>> "schemaLanguage" attribute of the corresponding <extension>
>  >>>>> element. For a particular <extension> declaration, if the WS-BPEL
>  >>>>> processor does not understand a particular schemaLanguage and
>  >>>>> mustUnderstand is set to no, the processor does not need to
>  >>>>> perform syntax validation. On the other hand, if mustUnderstand of
>  >>>>> the <extension> element is set to yes under the same unsupported
>  >>>>> schemaLanguage situation, the processor MUST reject the process
>  >>>>> definition during static analysis.
>  >>>>>
>  >>>>> If the "schemaLanguage" attribute at <extension> element is
>  >>>>> omitted, the default value will come from the "schemaLanguage"
>  >>>>> attribute of the parent <extensions> element.
>  >>>>>
>  >>>>> There is no default value for "schemaLanguage" attribute at
>  >>>>> <extensions>.
>  >>>>>
>  >>>>>
>  >>>>> Syntax summary:
>  >>>>> -------------------------
>  >>>>> <extensions schemaLanguage="URI"?>
>  >>>>>     <extension namespace="URI" mustUnderstand="yes|no"
>  >>>>>                schemaLocation="URI"? schemaLanguage="URI"? />*
>  >>>>> </extensions>
>  >>>>> -------------------------
>  >>>>>
>  >>>>> For example:
>  >>>>> --------------------------
>  >>>>> <extensions schemaLanguage="http://www.w3.org/2001/XMLSchema";>
>  >>>>>     <extension namespace="http://foo.com"; mustUnderstand="yes"
>  >>>>>           schemaLocation="http://foo.com/wsbpel/extension.xsd"; />
>  >>>>>     <extension namespec="http://bar.com"; mustUnderstand="no" />
>  >>>>>     <extension namespec="http://bar2.com"; mustUnderstand="yes" />
>  >>>>>     <extension namespec="http://some.org"; mustUnderstand="no"
>  >>>>>           schemaLocation="http://some.org/wsbpel/extension.rng";
>  >>>>>           schemaLanguage="http://relaxng.org/ns/structure/1.0"; />
>  >>>>> </extensions>
>  >>>>> --------------------------
>  >>>>>
>  >>>>> The extensions under namespace of "http://foo.com"; and
>  >>>>> "http://some.org"; are validated with schemas from
>  >>>>> "http://foo.com/wsbpel/extension.xsd"; (in W3C XML Schema) and
>  >>>>> "http://some.org/wsbpel/extension.rng"; (in Relax NG) respectively .
>  >>>>>
>  >>>
>  >
>  >
>  > ---------------------------------------------------------------------
>  > 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
> 
> 
> 


---------------------------------------------------------------------
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]