[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 11 - Call for Discussion
Alex Yiu wrote: > > Hi, all, > > I think Ron's assignment atomicity is a good point. > > Just want to supplement with some data points for consideration: > > XQuery actually has 2 facets: (1) one is the data is strongly typed > and associated with schema type and etc. (2) the other is the data > being constructed are typeless. > > E.g. the following is perfect runnable XQuery expression, which XQuery > engine does not need get any type information on <foo> > -------------------- > <foo> > for $x in $j/somexpath where ... return $x > </foo> > -------------------- > > Here is the XPath 2.0 and XQuery 1.0 type hierarachy diagram: > http://www.w3.org/TR/2003/WD-xpath-functions-20031112/XPathTypeHierarchySm.jpg > > > The yellow part in the diagram is handling the type-less situation, > which is essentally DOM! > > I expect XUpdate would try to continue the same type hierachy and try > to be symmetrical to XQuery in terms of dealing with BOTH type-ful and > type-less data. > > I guess it is over-simplified to say XUpdate is a type-ful update > language without mentioning the type-less data situation. > > It has been always the responsibility of a BPEL implementation to > handle transition from type-less data to type-ful data on the language > boundary. (e.g finding out schema type of an XPath 1.0 selection result.) > > And, XPath 1.0 is a language without XML Schema Type concept either. > Does it mean we should exclude XPath 1.0 also? > > Another data point is: the *first public draft* of W3C XUpdate would > not be available until the last quarter of 2004. > > As long as we restraint ourselves from solving the "world-hunger" > problem in the XML data manipulation context, I think we are safe to > add 3 new operations. mm1: I think providing sufficient parameters for data manipulation are important. Leaving these to unspecified means could impact portability. I support Ron and Alex's suggestions. >> Goland: DOM is a completely untyped API. BPEL is a heavily typed >> language. The two don't go well together. As soon as someone needs to >> perform a manipulation that requires two or more steps, the >> intermediate steps placing the target variable in an inconsistent >> state, BPEL's typing rules will be violated. This then leads us to >> introducing some kind of magic scope where the validation rules >> aren't enforced. But that leads to the problem of what happens if a >> fault occurs inside of the magic scope? This then leads us to >> introduce transactions into BPEL. Yuck. >> >> Ten-Hove: This is why <assign> is atomic. The intermediate states are >> never exposed. >> >>> Goland: As for XUPDATE, its mandate is to deal with how to perform >>> XML manipulations in heavily typed environments. Therefore it is a >>> much better match for BPEL's needs than the DOM and therefore when >>> it is released it will probably quickly replace DOM usage in BPEL. >>> >>> As for companion languages, for a companion language to BPEL to be >>> useful it must be able to see and manipulate BPEL variables. So it >>> seems reasonable to expect to be able to drop down into the >>> companion language, manipulate the BPEL variables using the >>> companion language's XML manipulation facilities and then pop back >>> up into BPEL. >> >> Ten-Hove: Is it your assertion that we should create a standard that >> MUST be supplemented by an unspecified companion language, in order >> to create executable processes? >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]