XSLT and Schema

[djharris]

I've ordered some books and I've been googling like crazy but it seems there's a disconnect between XSLT and the schema of the XML file I'm transforming. I can't figure out how to determine the node type and I also need to pull all the possible elements for the header list.

George already helped me get a list from the xml itself (thank you!) but since some elements are optional that won't always give me a complete list. I realize I could fill in those records to do this but since we're not the source of the xml it would be better if I could pull it from the schema.

So, I'm wondering if there's a way to take advantage of the xsd of the xml file I'm transforming. Specifically, can someone point me to solutions to the following?:

• A way to determine the xsd-defined type of a node (xs:int, xs:string, xs:decimal, etc.)
• A way to pull the element names from the xsd. Specifically, if minOccurs="0" I can't just pull them from the XML reliably as they may not be used in a particular "record"
• I've seen mention of some extensions (like MSXML) that may or may not still be around? Is there a good set of extensions/templates/functions I should be looking at to make life easier? Something tied to the transformer even? I see that there's entry points for them in Oxygen. FWIW, we're a Windows-based shop that mostly does Java development, and that's eventually where I'll be heading with this. Maybe that's relevant.

Sorry for being such a noob, but if anyone can help...

[george]

That does not look like an easy problem.
One possible approach is to try Saxon SA (oXygen 10 contains a license for that) and you should be able to get some schema information for the current node. However, I do not know if that gives you access to the content model for an element in order to see what possible elements can be put there... One approach may be to access the schema document and process that with a stylesheet - you have one example that does a similar processing in the stylesheet used by oXygen to create the XML schema documentation, you can find that in oXygen/frameworks/xs3p/xs3p.xsl, but that is a complex stylesheet.

Regards,
George

[djharris]

Bummer. I was hoping I was just missing the right keywords when searching.

I've been looking at Saxon-SA and noticed it already doesn't like that I'm calling a function that takes an xs:string on every node. I'm thinking a "negative" check against that might be where I need to head but I'm not sure on how to respond to the error. Any experience with that?

[djharris]

Actually, maybe there's an easier way to deal with this. I have the requirement of creating a csv from a customer's xml, but their xsd leaves every field optional (minOccurs="0"). Short of requiring them to change the xsd, can you think of a way for me to force every field to be created via XSLT? I tried just putting defaults in the XSD but that doesn't seem to help.

[george]

The default property for an element in XSD refers to its value, not to the element itself.
Now, if you do not want a very generic solution and you can constraint the schema to a few patterns then you should be able to get what elements are possible inside an element by accessing the schema (with the document function) and finding what xs:element with @ref or @name attribute appear in the element declaration of the element you are interested in.

Best Regards,
George