Webmaster wrote: >> Tony Gravagno wrote: >> MS .NET is built on XML. One of the core functions of >> this technology is parsing to/from XML using schema. > > Gah. .NET is wasted data bloat when you really need a > specific and potentially static XML format for data > transport. Just because .NET uses XML as a layer doesn't > make it the best fit for all XML solutions. You know that > better than anyone, T! :P
Sure, I've used XML in many different ways precisely because there is no best fit for all solutions. (Wasted most of my time on DTD but that's another story.) I didn't mean to imply that XML is easy with .NET because .NET is built on XML. I'm saying the .NET Framework has a well documented class library dedicated to making it easy to work with XML, and this can be invoked from U2 or with U2 as a data source. Don't take my word for it, here's one reference: http://tinyurl.com/drf5q And 170,000 more: http://www.google.com/search?hl=en&q=xml+ado.net+schema > Plus, there's more XML > development tools out there than the .NET development > suite and the .NET framework for Windows. Yes, but the question was asked and .NET wasn't one of the solutions presented, even though large companies like SAP are spending billions of dollars to implement solutions around this technology. > PHP and Perl > both have native XML handling modules that work either as > DOM or SAX parsers and validators. There's the Xerces and > Cocoon library sets for lower level languages. I > implemented cXML integration long before .NET was even > considered a "technology" in Windows, using samples from > the Xerces ANSI C dev kit and some dataBASIC. I think the chances of an MV developer using the Xerces ANSI C dev kit are far less than than an MV developer using VB.NET or C#. I agree that PHP and Perl have excellent XML handling, but those tools are usually used in a different context than I had in mind. I was thinking it would be easy to have a single executable which imports U2 data into a data set on one side, then have a mapping of such data to a schema on the other side, and then use a small bit of code (like one line?) to do the conversion in between. This is not a simple solution like the Web Services thing but it can be just as simple and effective as any other presented here so far. > I don't have the XML Bible and I probably won't buy it. > That's like buying a book on buying books. It's really > pointless unlesss you have no clue what XML really is. Funny you should say that. I bought it for my wife several years ago. She was asked by one of her clients, a prominent MV-based company who shall remain nameless, if she could work with them on their XML strategy. At the time neither she nor they had a clue about XML. > If you know what XML is, you can find tools to help you > design a solution or buy the solution you need to make > something happen. Glen, gear heads like us do our R&D off the net, and I'm nowhere near as gear-headed as you in most areas. :) This solution that George is looking for isn't one of the easy ones. Most people will probably buy the books and try to do it on their own. Then they'll realize they can't do it by reading a single book and they either drop the project or call for help. > Regardless, data format specs are typically backwards compatible. I was referring to syntax for SOAP, XML-RPC, XPath, XQuery, and other fledgling protocols and languages that we find in books from Wrox Press, Que, IDG and others. The books are often bleeding edge, at the risk of being invalid as soon as they hit the shelves. > The key is to find out > what your requirements are, to meet guidelines for the > implementation. If you can meet the specs for the current > guidelines, then make sure that your design is > considerate of additional elements and attributes. > Anytime you solidify your design around a single document > spec, you'll be stuck there forever or until someone has > the guts to rip it all apart and rebuild it. Agreed. The thing to do as your writing this stuff is to ask yourself how much you'd need to rip up if someone decides to add a new node next month. If your answer is "oh crud" or something similar then consider a different approach. T > Check out this MARC to ONIX translation map for XML > reference. There is a MARC::XML module for Perl, if the > data you're access is in MARC format. > http://www.loc.gov/marc/onix2marc.html#mapping > > There is a raw XML parser on http://picksource.com, which > I posted a long time ago. It translates the elements, > attributes/values, and element values into a > 3-dimensional MV array. Patrick Payne posted a GPL XML > tool kit, which provides node extraction, node insertion, > and other useful functions. > > Glen > http://mvdevcentral.com > http://picksource.com > ------- ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
