Hi All,
I have a server job that reads from a Database table, applies some transform and then outputs to an XML Output stage. The XML Output stage is designed to generate output based on an imported XSD.
I need to output a particular value if the schema definition has a specific rule for a column.
e.g. If the schema definition allows a column to be null, then i would like to output an attribute xsi:nill = "true" for this element.
Is there a way to access the schema from within a transform stage (or some other stage) during run-time and make this output happen?
Let me know if i need to explain this a bit more.
Thanks in advance for your time
Accesing XML Schema in a Job
Moderators: chulett, rschirm, roy
hmm. Interesting problem. I'm not sure whether the XMLOutput stage will do this for you if the column value is NULL, but I tend to doubt it... this would require further testing, but you should be able to force the attribute yourself...
Create a column called something like nilStatusCompany (where Company is the name of your column/element), give it a char datatype and short length. Set it to "true" if the value in "Company" is truly NULL (test this and set it in a transformer beforehand) or "false" otherwise [note, I haven't seen xsi:nil=false used in many documents, but the xml schema spec shows nil as boolean, so it should be legal].
Then include it on the input link of your XMLOutput Stage, prior to the actual column that is that element, with the following XPath in the description:
nilStatusCompany ............. /otherElementsInPath/Company/@xsi:nil
Company /otherElementsInPath/Company/text()
Be sure also to include a namespace declaration for xsi in the Output link details tab. There's a checkbox there, and the string should look something like:
xmlns:xsi="proper URL for the xsi namespace"
Let us know how it goes.
Ernie
Create a column called something like nilStatusCompany (where Company is the name of your column/element), give it a char datatype and short length. Set it to "true" if the value in "Company" is truly NULL (test this and set it in a transformer beforehand) or "false" otherwise [note, I haven't seen xsi:nil=false used in many documents, but the xml schema spec shows nil as boolean, so it should be legal].
Then include it on the input link of your XMLOutput Stage, prior to the actual column that is that element, with the following XPath in the description:
nilStatusCompany ............. /otherElementsInPath/Company/@xsi:nil
Company /otherElementsInPath/Company/text()
Be sure also to include a namespace declaration for xsi in the Output link details tab. There's a checkbox there, and the string should look something like:
xmlns:xsi="proper URL for the xsi namespace"
Let us know how it goes.
Ernie
I haven't found a way and this *is* something we actually futzed with at one point. We ended up having to take the 'force it yourself' route.eostic wrote:I'm not sure whether the XMLOutput stage will do this for you if the column value is NULL, but I tend to doubt it... this would require further testing, but you should be able to force the attribute yourself...
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
I just stumbled across a section of the online help for the XML Output stage that says:
'Validation against an XML schema is required when you want default values for elements and attributes that are specified in the schema written to an output row. To reference a schema in your XML document, use the schemaLocation attribute within the root element tag'.
Perhaps that's the answer to the nillable issue?
'Validation against an XML schema is required when you want default values for elements and attributes that are specified in the schema written to an output row. To reference a schema in your XML document, use the schemaLocation attribute within the root element tag'.
Perhaps that's the answer to the nillable issue?
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
hmm. Good question. I tested this when the pack was new, and just went back and looked at my notes. It works fine for strings, but I didn't check default of NULL. Usually defaults are important when "reading" a document and an element isn't there (simply isn't in the xml instance at all) and you still want a value to show up in your application [or in DS's case, a column].
Another test to put on the agenda.
Except for small documents, validating usually results in paying too much of a performance price, so it is generally avoided in practice. On the other hand, I've always thought it was a great idea, and would be a good way to do enumerated type validations instead of coding up transformers and other functions for relatively fixed "list checking". I haven't seen it used much though, for any applications, let alone DataStage. Only once have I helped a customer do validation, then send the output back to the source [a partner application] for repair.
Ernie
Another test to put on the agenda.
Except for small documents, validating usually results in paying too much of a performance price, so it is generally avoided in practice. On the other hand, I've always thought it was a great idea, and would be a good way to do enumerated type validations instead of coding up transformers and other functions for relatively fixed "list checking". I haven't seen it used much though, for any applications, let alone DataStage. Only once have I helped a customer do validation, then send the output back to the source [a partner application] for repair.
Ernie
Hi Ernie & Group,
Thanks a lot for your inputs. Much appreciated. The recommendation by Ernie to force an attribute works fine. That was helpful.
As you mentioned, this does not use the XSD information to interpret the NILLABLE property at runtime, but relies on prior information (coded at design time) within the transformer to make this work for certain fields in a predefined manner.
It works for us at this time. If we run into a situation where further research is needed, i will dig further.
Thanks for your time
Thanks a lot for your inputs. Much appreciated. The recommendation by Ernie to force an attribute works fine. That was helpful.
As you mentioned, this does not use the XSD information to interpret the NILLABLE property at runtime, but relies on prior information (coded at design time) within the transformer to make this work for certain fields in a predefined manner.
It works for us at this time. If we run into a situation where further research is needed, i will dig further.
Thanks for your time