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: Fw: [wsbpel] Issue - 157 - conf call brief recap ... and carryforward ...



Hi Rania,
(adding Chris to the explicit cc list)

Well ... the trip is highly work related ... :-)

> So when is a simple type var considered an EII and when is it 
> considered a TII ? For the purposes of assign, are you saying that it 
> is considered a TII  ?

A simple type variable is always manifested as TII or an expression 
language data-object (e.g. boolean and number in XPath 1.0) (not just 
for purpose of assign). On the flip side, for purpose to describe the 
context of TII in the XML infoset item terms, we create an anonymous 
element as the parent of the TII.


About the Element-with-Simple-Content, it is used to distingush from the 
case of Element-with-Complex-Content. When we are dealing an 
Element-with-Simple-Content, we can enable Replace-Content from a 
simple-type value to such an Element (with Simple Content).

The motivations of enabling such a Replace-Content are listed as 
follows: (actually, they were briefly discussed in previous smaller 
group conf call before)

    * _maintain more symmetrical cases between "equal" and "copy" and
      matches with the node value concept of XPath1.0/XPath2.0's data
      model better_:

      e.g.: If enable such a "Replace-Content"

      "$nameVar/firstNameElem = 'John' "
           [The XPath equal operation is comparing
            the value of "firstNameElem" node and
            the value of 'John' string liternal ]

      and

      <assign> <copy>
           <from> 'John' </from>
           <to> $nameVar/firstNameElem </to>
      </copy> </assign>

      are now symmetrical.

    * _match schema-based concepts better_: Say above "firstNameElem"
      has the following XSD definition:
      <xsd:element name="firstNameElem" type=xsd:string" />

      The above symmetry even makes more senses in the light of schema.
      It is very natural for people to assign a String value to a field
      of String type under "nameVar" directly, where the field is under
      an element structure in this case.

      (Similar situation applies to attribute: i.e. people would
      naturally assign a String value to a field of String type, where
      the field is under an attribute structure.) 

      [ Chris (Keller) has used a similar example in a previous conf call. ]

    * _user convenience_: In theory, people always add "text()" to make
      the XPath to look like this: "$nameVar/firstNameElem/text()".
      IMHO, save users' extra step to add text() is definitely a good
      thing to do for usability without introducing any ambiguity or
      downside.




Regards,
Alex Yiu



Rania Khalaf wrote:

>
> Hi Alex,
>
> Hope your trip is going well, and that you have time to sneak in some 
> hanging out while you're all the way over there ! Sounds exciting :)
>
> So when is a simple type var considered an EII and when is it 
> considered a TII ? For the purposes of assign, are you saying that it 
> is considered a TII  ?
>
> If so, then why do we need the Element-with-Simple-Content row. I 
> thought that was the compelling use case for it (it would arguably be 
> strange for the user to think of doing text() on a simple type var) 
> but now I see that it's not the case.
>
> They should use text() - or if they want to copy the attribute, they 
> should point at the attribute. I really think in the interest of 
> clarity, that row should be axed since it is redundant.
>
> I see now that AII/TII cannot be collapsed since AII value is not a 
> TII (not a node), but with the EII with simple content, I think it's 
> strange behavior we don't need at all because the designer can be 
> specific.
>
> Regards,
> Rania
>
> Alex Yiu wrote:
>
>>
>> Hi Rania,
>>
>> Sorry for replying a bit late ... (still traveling in Hong Kong / 
>> China as of this moment)
>> Yes, a simple type variable can be manifested as an EII (anonymous) 
>> with a simple content. However, in that case, the variable actually 
>> points to the Text node under the Element. That means, 
>> "$aSimpleTypeVar" points to the text node, NOT the element node.
>> (I will reply your "replaceElementName"-related question in a 
>> separated email.)
>>
>> Thanks!
>>
>>
>> Regards,
>> Alex Yiu
>>
>>
>> Rania Khalaf wrote:
>>
>>> Hi Alex,
>>>
>>> In this table, is a variable typed using an xsd simple type 
>>> considered EII-with-simple-content (spec says something to that 
>>> effect I believe, regarding $var)? Does copying into a var typed 
>>> with XSD type then fall into the EII column ?
>>>
>>> I am not pointing to a potential problem :) just trying to 
>>> understand your table.
>>>
>>> tks
>>> Rania
>>>
>>> Alex Yiu wrote:
>>>
>>>>
>>>> Hi, all,
>>>>
>>>> >From the sub-group conf call, I got an action item to clarify the 
>>>> difference between  "string-value" and "text-node" and verify how 
>>>> it affects the replacement table.
>>>>
>>>> Actually after more thinking, we do not need to modify the "F2F 
>>>> Table" in general ...
>>>>
>>>> -------------------------------------------
>>>> The "F2F Table":
>>>> From \ To
>>>>     EII
>>>>     AII
>>>>     TII
>>>> EII with
>>>> Complex-Content
>>>>     RE
>>>>     F
>>>>     F
>>>> EII with
>>>> Simple-Content
>>>>     RE
>>>>     RC
>>>>     RC
>>>> AII
>>>>     RC
>>>>     RC
>>>>     RC
>>>> TII
>>>>     RC
>>>>     RC
>>>>     RC
>>>>
>>>> -------------------------------------------
>>>>
>>>> ... I think we just need to add some clarification to the 
>>>> definition of TII and a footnote to this table:
>>>>
>>>> -------------------------------------------
>>>> *Clarified Definition of TII: *(to be added)
>>>> TII is a sequence of _zero or more_ CII. When it is mapped to XPath 
>>>> 1.0 model, it is a generalization of String-Value (which has zero 
>>>> or more characters) and Text Node (which has one or more 
>>>> characters). RValue of a TII can be mapped to a String-Value or a 
>>>> Text Node in XPath 1.0, while LValue of a TII can be only mapped to 
>>>> a Text node.
>>>>
>>>> *Foot-note to the "F2F-Table"*:
>>>>
>>>>     * Information items referenced by the to-spec MUST be a Lvalue.
>>>>       (As stated in Issue 103)
>>>>     * In XPath 1.0 data model, only Text Node can constitute a LValue
>>>>       of TII.
>>>>
>>>> -------------------------------------------
>>>>
>>>>
>>>> I think that should be good enough.
>>>> What do you guys think?
>>>>
>>>>
>>>>
>>>> Regards,
>>>> Alex Yiu
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]