[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]