Discussion on:
View:
Show:
Why not just use XSL transformations with its built-in support for XPath?
than anything else, agreed XSLT is a far better option for xml to xml.
For small xml docs much ease to visualy map xml to xml, use tool that allow u convert it to xslt add needed logic. However, when one has rich xml (a lot of field and deep structure) and output structure is much different then xslt file is huge and hard to maintain. I wonder what happens in this approach consider that one wants to keep rules in xml?
on complex documents, large doesn't really matter.
All depends on how much meta data particularly layout characteristics you want to put in the source xml.
Not knocking the idea itself, but the need for this tool, to me indicates a poor technology choice ,xsl that is not your tool.
All depends on how much meta data particularly layout characteristics you want to put in the source xml.
Not knocking the idea itself, but the need for this tool, to me indicates a poor technology choice ,xsl that is not your tool.
Our main idea was to create mapping file for
to be able easy maintain changes.
to be able easy maintain changes.
It might be all you can do and a visual tool should be easier than typing away in an xslt editor.
I'm looking at ways to reduce the complexity at the moment as opposed to coping with it. Of course a solution like that is not going to be generic.
Currently I'm looking at successively applying style sheets to a hosted document.
I am going to have to do some stuff xslt will just not cope with at all or at best not very well. So I'm trying to find a balance so neither is too complex.
I've always been a big fan of piped processes. I like the idea of being able to validate the intermediate products, so instead of doing a hideously complex mapping on each input node in one enormous style sheet, I'm looking at breaking it down into a number of well defined passes. This makes the individual mappings trivial, hence no need for your tool.
It will be a lot of effort but it's going to get used and reused a lot and the documents are controlled by the government and changed to cope with their requirements, no matter how much of a problem it might cause anyone else.
I'm looking at ways to reduce the complexity at the moment as opposed to coping with it. Of course a solution like that is not going to be generic.
Currently I'm looking at successively applying style sheets to a hosted document.
I am going to have to do some stuff xslt will just not cope with at all or at best not very well. So I'm trying to find a balance so neither is too complex.
I've always been a big fan of piped processes. I like the idea of being able to validate the intermediate products, so instead of doing a hideously complex mapping on each input node in one enormous style sheet, I'm looking at breaking it down into a number of well defined passes. This makes the individual mappings trivial, hence no need for your tool.
It will be a lot of effort but it's going to get used and reused a lot and the documents are controlled by the government and changed to cope with their requirements, no matter how much of a problem it might cause anyone else.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
