Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 130281 - Better support of XSD types extension/restriction
Better support of XSD types extension/restriction
Status: VERIFIED FIXED
Product: soa
Classification: Unclassified
Component: BPEL Validation
6.x
All All
: P1 (vote)
: 6.x
Assigned To: Vladimir Yaroslavskiy
issues@soa
61fixes2-fixed
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-17 14:01 UTC by Sergey Lunegov
Modified: 2008-07-10 15:14 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Test project (85.82 KB, application/x-compressed)
2008-05-22 15:18 UTC, Vladimir Yaroslavskiy
Details
Test project with only one copy (85.83 KB, application/x-compressed)
2008-05-22 15:19 UTC, Vladimir Yaroslavskiy
Details
Test project, version 3 (86.08 KB, application/x-compressed)
2008-05-23 12:01 UTC, Vladimir Yaroslavskiy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Lunegov 2008-03-17 14:01:18 UTC
[filing on behalf of Michael Czapski]

In HL7 XSD schemas use type extensions pretty wide. In BPEL Mapper there are a number of restriction to deal with such
situations. See mail excahnge between Kirill and Michael.

The trouble for me is that the mapper does not believe this element is a string, bepl 2.0 editor complains that I am
trying to assign string to PID.3.CONTENT and refuses to show me the mapping when I try to switch back to the mapper form
design mode.
In your picture teh pointer is hovering over node Type, which is an attribute declared with type xsd:string. Nowhere do
I see the type of the actual PID.x.CONTENT so perhaps the mapper cannot figure out what the type is and complains. over
the pointer over the CM_PAT_ID.x and see what type that is. I need to assign a string value to the element, not the
attributes.

Regards

Michael


Kirill Sorokin wrote:
> Does it really?
>
> From what I see, PID.3 is declared this way (cleaned-up a little to
> improve readability):
>
> <xsd:attributeGroup name="PID.3.ATTRIBUTES">
>     <xsd:attribute name="Item" type="xsd:string"/>
>     <xsd:attribute name="Type" type="xsd:string"/>
>     <xsd:attribute name="LongName" type="xsd:string"/>
> </xsd:attributeGroup>
> <xsd:complexType name="PID.3.CONTENT">
>     <xsd:complexContent>
>         <xsd:extension base="CM_PAT_ID">
>             <xsd:attributeGroup ref="PID.3.ATTRIBUTES"/>
>         </xsd:extension>
>     </xsd:complexContent>
> </xsd:complexType>
> <xsd:element name="PID.3" type="PID.3.CONTENT"/>
>
> The base type, CM_PAT_ID:
>
> <xsd:complexType name="CM_PAT_ID">
>     <xsd:sequence>
>         <xsd:element ref="CM_PAT_ID.1" minOccurs="0" maxOccurs="1"/>
>         <xsd:element ref="CM_PAT_ID.2" minOccurs="0" maxOccurs="1"/>
>         <xsd:element ref="CM_PAT_ID.3" minOccurs="0" maxOccurs="1"/>
>         <xsd:element ref="CM_PAT_ID.4" minOccurs="0" maxOccurs="1"/>
>         <xsd:element ref="CM_PAT_ID.5" minOccurs="0" maxOccurs="1"/>
>     </xsd:sequence>
> </xsd:complexType>
>
> CM_PAT_ID.X are all declared in the same way:
>
> <xsd:attributeGroup name="CM_PAT_ID.1.ATTRIBUTES">
>     <xsd:attribute name="Type" type="xsd:string"/>
>     <xsd:attribute name="LongName" type="xsd:string"/>
> </xsd:attributeGroup>
> <xsd:complexType name="CM_PAT_ID.1.CONTENT">
>     <xsd:simpleContent>
>         <xsd:extension base="ST">
>             <xsd:attributeGroup ref="CM_PAT_ID.1.ATTRIBUTES"/>
>         </xsd:extension>
>     </xsd:simpleContent>
> </xsd:complexType>
> <xsd:element name="CM_PAT_ID.1" type="CM_PAT_ID.1.CONTENT"/>
>
> The ST type is an empty restriction of xsd:string. Given all this,
> element PID.3 should have three attributes: Item, Type, LongName and
> five children CM_PAT_ID.1 .. CM_PAT_ID.5, each having two attributes --
> Type, LongName -- and a string content. This is exactly what I see in
> the mapper tree (see the attached image). Please let me know if I'm
> missing something..
>
> Thanks,
> Kir
>
> Michael Czapski wrote:
>> It seems that the nodes in the HL7 structure only expand so far and no further.
>>
>> T\he structure definition in the XML schema document says this:
>>     <!--
>>         FIELD PID.3
>>     -->
>>     <xsd:attributeGroup name="PID.3.ATTRIBUTES">
>>         <xsd:attribute name="Item" type="xsd:string" fixed="106"/>
>>         <xsd:attribute name="Type" type="xsd:string" fixed="CM"/>
>>         <xsd:attribute name="LongName" type="xsd:string" fixed="Patient ID (Internal ID)"/>
>>     </xsd:attributeGroup>
>>     <xsd:complexType name="PID.3.CONTENT">
>>         <xsd:annotation>
>>             <xsd:documentation xml:lang="en">Patient ID (Internal ID)</xsd:documentation>
>>             <xsd:appinfo source="urn:com.sun:encoder">
>>                 <hl7:Item>106</hl7:Item>
>>                 <hl7:Type>CM</hl7:Type>
>>                 <hl7:LongName>Patient ID (Internal ID)</hl7:LongName>
>>             </xsd:appinfo>
>>         </xsd:annotation>
>>         <xsd:complexContent>
>>             <xsd:extension base="CM_PAT_ID">
>>                 <xsd:attributeGroup ref="PID.3.ATTRIBUTES"/>
>>             </xsd:extension>
>>         </xsd:complexContent>
>>     </xsd:complexType>
>>     <xsd:element name="PID.3" type="PID.3.CONTENT"/>
>>
>> so it seems we stop at complexContent and do not get to the extension base.
Comment 1 Sergey Lunegov 2008-04-30 15:03:46 UTC
Nikita, what else should we do to implement the issue.
Comment 2 Vladimir Yaroslavskiy 2008-05-06 15:08:07 UTC
Mapper, validation, correlation wizard use one utility method getBuiltInSimpleType in class ValidationUtil
to check if two types are based on the same type. This method has been written by Alex Petrov, reassign
for furter investigation...
Comment 3 Vladimir Yaroslavskiy 2008-05-06 15:09:07 UTC
It would be nice to have a project...
Comment 4 Alexey Yarmolenko 2008-05-08 13:34:52 UTC
please  provide a sample project, so it would be easier for us to reproduce  and understand this problem.
Comment 5 Sergey Lunegov 2008-05-08 14:13:17 UTC
Nikita, looks like yours.
Comment 6 Sergey Lunegov 2008-05-21 15:41:12 UTC
Vladimir, I'll provide you the project
Comment 7 Vladimir Yaroslavskiy 2008-05-22 15:18:07 UTC
Created attachment 61767 [details]
Test project
Comment 8 Vladimir Yaroslavskiy 2008-05-22 15:19:59 UTC
Created attachment 61768 [details]
Test project with only one copy
Comment 9 Vladimir Yaroslavskiy 2008-05-22 15:50:59 UTC
My investigation:

1. Unzip and open test project UDToHL7 with only one copy (last attachment)
2. Open bpelUDToHL7.bpel file in source editor
3. Press "Validate XML" button (alt+Shift+F9)
4. See only one Warning (not Error !!!)

<NetBeansProjects>/UDToHL7/src/BPEL/bpelUDToHL7.bpel:21,12
WARNING: The types of "From" and "To" activities are different: "string" and "EVN.2.CONTENT".

for the copy

<from>'20060717142105+1000'</from>
<to>$xmlHL7Out.xmsHL7Out/ns0:EVN/ns0:EVN.2</to>

If you look at the chain: part xmsHL7Out -> element ADT_A04 -> complex type ADT_A04.CONTENT -> 
- > element EVN.2 -> type EVN.2.CONTENT, you see that the type EVN.2.CONTENT has complex
extension - attribute group - EVN.2.ATTRIBUTES which has several restricted attributes
"Item", "Types", "LongName"

So, xpath model identifies the input and output types correctly, therefore the string literal
'20060717142105+1000' can not be assigned to the complex type.

If specify the output type more precisely, for example add attribute "Item":

<from>'20060717142105+1000'</from>
<to>$xmlHL7Out.xmsHL7Out/ns0:EVN/ns0:EVN.2/@Item</to>

the validation passes without any warnings/errors.

Conclusion: from validation point of view, the output warnings are correct and
it works right. Changes should be done in the bpel mapper to work with extensions
and restrictions correctly.

Reassign to the owner of BPEL mapper...
Comment 10 Vladimir Yaroslavskiy 2008-05-23 11:53:55 UTC
After discussion with Kirill, we found that the problem is in finding of based simple built-in type. Validation uses
this utility method of finding of based simple built-in type (written by Alex Petrov) and compares the types of "from"
and "to" in copy. For special cases, it works incorrectly: doesn't support of extension/restriction. Reassign to
validation, I'll fix the utility method (xml.wsdl.extensions/../ValidationUtil class).
Comment 11 Vladimir Yaroslavskiy 2008-05-23 11:59:09 UTC
Please see attached updated project UDToHL7.v3:

There is a copy:

<copy>
  <from>'3.1415926'</from>
  <to>$xmlHL7Out.xmsHL7Out/ns0:PID/ns0:PID.3/ns0:CM_PAT_ID.1</to>
</copy>

The step CM_PAT_ID.1 has type CM_PAT_ID.1.CONTENT which simple context is extension of type "ST".
The type "ST" is restriction of built-in type "xsd:string". Therefore string literal "3.1415926"
can be assigned to the CM_PAT_ID.1
Comment 12 Vladimir Yaroslavskiy 2008-05-23 12:01:04 UTC
Created attachment 61821 [details]
Test project, version 3
Comment 13 Vladimir Yaroslavskiy 2008-05-23 12:06:26 UTC
Note that mapper shows schema structure correctly:

xmlHL7Out
  PID
    PID.3
      CM_PAT_ID.1

so there is no modification in mapper.
Comment 14 Vladimir Yaroslavskiy 2008-05-23 12:22:33 UTC
fixed: 8a0ca83aa8cf
Comment 15 pslechta 2008-05-28 14:13:43 UTC
QA, please verify this fix till 09-Jun-2008, so it can be part of NB 6.1 patch 2.
Comment 16 Andrei Chistiakov 2008-05-29 16:01:07 UTC
Verified with NetBeans IDE Dev (Build 200805280004).
Comment 17 pslechta 2008-05-29 16:23:46 UTC
The fix has been ported into the release61_fixes repository.

http://hg.netbeans.org/release61_fixes/rev/c0b32621fb2e


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo