Well, for one, the package isn't included in my standard Perl or the documentation.
Aside from that, I'd hazard that it's just as standard compliant as Stylus Studio or Altova XMLSpy, 2 of the generators I was speaking of. A generator/parser typically doesn't worry about if it can be read and deciphered by a human, just if it is conforming and passes well-formed and validity checks.
I needed something that I could quickly run an XSD through and then open the output and read it without too much difficulty.
But, if I could have done it an easier way, please, give me some details and I'll be glad to redo. As the Usage states, there are "Shortcomings:";)
thx,
Dave S. | [reply] |
After reading some of the documentation online, it would seem that there's a low level XML::Parser, which would be tantamount to just adding overhead to my already written code which I would just point to in the Parser class.
Similarly, the DOM module appears to be way more horsepower than the task requires, that is, it would just be adding additional overhead to the code I've already written.
At this particular point, I see no value added. However, if I'm being too naive, please, give me an example of how one of these packaged parsers might be used for simply reorganizing a file? They seem to me to be more for processing a file for a different kind of output.
thx,
Dave S. | [reply] |
Howdy!
It sounds like you want something to tidy up the use of white space
so the sucker is comprehensible to a human. XML::Tidy appears
to be a module that will do exactly this.
As to why you would take this path rather than the one you did? Well,
writing your code may well have been educational, but it fails to
constructively apply the virtue of laziness. It's not a sin to do that.
It simply means that you did work that was not necessarily necessary.
In addition, assuming that XML::Tidy does do the trick (something I
cannot comment on one way or the other), using that allows you to put
your energy into building on it rather than having to start by building
it. That is the value added by using someone else's work to start from.
| [reply] |
Hi!
No, I don't want to tidy the file, there's plenty of that in most any generator. The problem is, and I point out it is most specific to XSD, that generators of XSD don't generally care about "reading format", their concern is standards compliance. Typically, they'll generate a file and simply alphabetize the entries. That's okay if you already know the entries and can tell the generator which entry is the root when it goes to create an example/sample/template XML. But what if you don't know? What if you're looking at some other XSD file (also generated) from another source. Without careful study and, perhaps, a few trial and error passes, you may not get a correct XML example/sample/template. What I've tried to do with ReorgXSD is do some of the "study" and reorganize the XSD into a file that more readily reveals what the structure of the XML will be, most importantly, what is the root element?
It might be profitable for you to take the code, apply it to a less than decipherable XSD and see if you don't think the output is easier to read/understand.
I've tried it with various XSD's from Altova, Stylus Studio, and Microsoft, both existing in their downloads and generated by them. I've found that most of the time, the reorg makes the XSD easier to read/understand. But that, of course, is subjective. Perhaps for many people who've been around XSD since it's inception, ReorgXSD files are no better than the original.
thx,
Dave S.
| [reply] |