This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[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.
Nikita, what else should we do to implement the issue.
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...
It would be nice to have a project...
please provide a sample project, so it would be easier for us to reproduce and understand this problem.
Nikita, looks like yours.
Vladimir, I'll provide you the project
Created attachment 61767 [details] Test project
Created attachment 61768 [details] Test project with only one copy
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...
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).
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
Created attachment 61821 [details] Test project, version 3
Note that mapper shows schema structure correctly: xmlHL7Out PID PID.3 CM_PAT_ID.1 so there is no modification in mapper.
fixed: 8a0ca83aa8cf
QA, please verify this fix till 09-Jun-2008, so it can be part of NB 6.1 patch 2.
Verified with NetBeans IDE Dev (Build 200805280004).
The fix has been ported into the release61_fixes repository. http://hg.netbeans.org/release61_fixes/rev/c0b32621fb2e