| | |
XML Transformations
Please support our XML, XSLT and XPATH advertiser: Intel Parallel Studio Home
Thread Solved |
•
•
Join Date: Jul 2006
Posts: 22
Reputation:
Solved Threads: 0
Hi guys i am pretty new to XML. Well I have transform a xml file in format A(let's say) to format B. By surfing the websites, I found that XLST can do this.But these 2 formats dun not neccesarily have easy transforms like tag-to-tag. They can be transformed from tag-to-tag,tag-to-attribute etc.. So in this case is XLST should still be able to achieve the needs or should I have to resort to SAX or DOM.And again which is better.. Thanks in advance..
XSLT is the tool for the job, you just need to write an XSLT stylesheet to perform the transformation you want, and away you go.
How you write that XSLT is the tricky part, books have been written about it. It's a complex programming language in its own right.
How you write that XSLT is the tricky part, books have been written about it. It's a complex programming language in its own right.
As people are clearly allowed to attack me but I'm not allowed to defend myself, I no longer post to this site.
XSLT processors generally use SAX and DOM as the core parser and RAM organisation method respectively.
SAX is a very low-level XML-to-event-chain parser, and DOM is just a list of interconnected nodes.
XSLT is a definition language that can sit on top of that, controlling the process of turning an input DOM into an output DOM.
Anything you write in XSLT could be implemented using SAX and DOM, but a single-input-file-to-single-output-file transformation (or even a multi-input-file-to-single-output-file transformation) is a relatively simple XSLT process whatever the rules for it are, and you should use XSLT.
<xsl:apply-templates> and mode will be your best friends =P
I'd advise learning the XPath rules for node selection (http://www.w3.org/TR/xpath)
and getting yourself a good XSL processor (http://xalan.apache.org/)
SAX is a very low-level XML-to-event-chain parser, and DOM is just a list of interconnected nodes.
XSLT is a definition language that can sit on top of that, controlling the process of turning an input DOM into an output DOM.
Anything you write in XSLT could be implemented using SAX and DOM, but a single-input-file-to-single-output-file transformation (or even a multi-input-file-to-single-output-file transformation) is a relatively simple XSLT process whatever the rules for it are, and you should use XSLT.
<xsl:apply-templates> and mode will be your best friends =P
I'd advise learning the XPath rules for node selection (http://www.w3.org/TR/xpath)
and getting yourself a good XSL processor (http://xalan.apache.org/)
Plato forgot the nullahedron..
•
•
•
•
Anything you write in XSLT could be implemented using SAX and DOM,
XSLT is relatively easy to learn (though hard to master), reasonably fast (if you know what you're doing), and extremely flexible.
As people are clearly allowed to attack me but I'm not allowed to defend myself, I no longer post to this site.
•
•
Join Date: Jul 2006
Posts: 22
Reputation:
Solved Threads: 0
hi guys, sorry for the late reply..Was away for a few days.
Anyways, my collegue passed me a partially completed xsl file and he told me, he was using Pyana (XSL parser)..
What I want to know is that how can I ensure that the xsl file will completely parse all tags and attributes..I could try tens of xml files but it still wouldnt be exhaustible so Can i transform the schema of input file and get the schema of the output file and then compare whether it is equal with given schema of output file..
Thanks
Anyways, my collegue passed me a partially completed xsl file and he told me, he was using Pyana (XSL parser)..
What I want to know is that how can I ensure that the xsl file will completely parse all tags and attributes..I could try tens of xml files but it still wouldnt be exhaustible so Can i transform the schema of input file and get the schema of the output file and then compare whether it is equal with given schema of output file..
Thanks
Unless your input stylesheet is extremely simple, the XSL processor deliberately wont parse all tags in an input file. XSL is like a data filtering language... it absolutely depends on you knowing the input schema, and knowing how to translate every part of the input document into an output document.
It's also quite top-down. Unless you make very generalized rules, you have to manually apply a transform directive to every node/set in your input documents that are important in the output document,
You should think of schema as being a set of unbreakable rules for the organisation of and type of content in a file; and XSLT as a way of moving content from a document of one schema to a document of another (or the same) schema.
XSL transformations themselves only neccessarily acknowledge the XSL namespace schema. An XSL transformation will not generate (or neccessarily comply with) an explicit schema defintion for an output document. There may be a way to enforce output document schema validity at a low level... I've never come accross it.
There's a few online tools for checking the validity of documents based on an explicit schema, I don't know if that's what you're looking for:
http://tools.decisionsoft.com/schemaValidate/
and offline tools:
http://www.altova.com/products/xmlspy/xml_editor.html
In my experience, the best way to test input against output is to create a load of test cases (documents that cover most potential inputs to a stylesheet) and transform them.
If your input documents could deviate greatly in structure, perhaps you should consider redesigning your input document's schema, or using multiple input schema/documents//stylesheets, and (if neccessary) transforming them into a single file.
It's also quite top-down. Unless you make very generalized rules, you have to manually apply a transform directive to every node/set in your input documents that are important in the output document,
You should think of schema as being a set of unbreakable rules for the organisation of and type of content in a file; and XSLT as a way of moving content from a document of one schema to a document of another (or the same) schema.
XSL transformations themselves only neccessarily acknowledge the XSL namespace schema. An XSL transformation will not generate (or neccessarily comply with) an explicit schema defintion for an output document. There may be a way to enforce output document schema validity at a low level... I've never come accross it.
There's a few online tools for checking the validity of documents based on an explicit schema, I don't know if that's what you're looking for:
http://tools.decisionsoft.com/schemaValidate/
and offline tools:
http://www.altova.com/products/xmlspy/xml_editor.html
In my experience, the best way to test input against output is to create a load of test cases (documents that cover most potential inputs to a stylesheet) and transform them.
If your input documents could deviate greatly in structure, perhaps you should consider redesigning your input document's schema, or using multiple input schema/documents//stylesheets, and (if neccessary) transforming them into a single file.
Plato forgot the nullahedron..
![]() |
Similar Threads
- Transforming xml into pdf (C#)
- Asp+xml+mssql (ASP)
- Php parser error when xml version is mentioned (PHP)
Other Threads in the XML, XSLT and XPATH Forum
- Previous Thread: Weather Feed Reader
- Next Thread: XML Transforming Help
| Thread Tools | Search this Thread |
api blogger blogging code delete development dynamiccreationofnvariablesinxslt error firstthreecharacterofastringrequired flipbook gdata google html include java link linspire linux microsoft news node openoffice overwrite precedence programming rss standards swf template transform variable w3c web xml xmlnotloading xmlonserver xsl xslt






