Posted: Wed May 01, 2013 5:21 am
Not sure what you are proposing, unless we are all still mis-understanding the objective. I am under the impression that the goal is to match the actual "documentation string" from the xsd next to each of the possible enumerated values that might be flowing down from an individual instance document...
meaning that for a particular value in an element or attribute flowing thru the job, they don't want the value, they want what is in the documentation element of the xsd...
...ie...when the value in the document is "4", use this string from the xsd:
<xs:documentation>Closed G</xs:documentation>
So...at some point, i/o has to be performed on the xsd itself. How that xsd is parsed of course, is simply a developer choice...with stage or with xslt...either or something else would be fine --- but it contains the values that are desired for each matching value.
...or maybe I still don't understand the initial objective. ; )
Ernie
meaning that for a particular value in an element or attribute flowing thru the job, they don't want the value, they want what is in the documentation element of the xsd...
...ie...when the value in the document is "4", use this string from the xsd:
<xs:documentation>Closed G</xs:documentation>
So...at some point, i/o has to be performed on the xsd itself. How that xsd is parsed of course, is simply a developer choice...with stage or with xslt...either or something else would be fine --- but it contains the values that are desired for each matching value.
...or maybe I still don't understand the initial objective. ; )
Ernie