> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Tony Gravagno > Sent: Tuesday, September 20, 2005 7:57 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] UV and XML Schema > > > I've seen the other suggestions but I'll add the following: > MS .NET is built on XML. One of the core functions of this technology is > parsing to/from XML using schema. Rather than trying to > parse/interpret/generate raw XML on your own, you may want to consider > using free technology that was designed for the purpose, then your > interface to/from U2 is plain text in whatever format you want. Some of > this is truly as simple as using just a couple lines of code.
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 Plus, there's more XML development tools out there than the .NET development suite and the .NET framework for Windows. 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. > > Regarding books, I'm not to impressed with the XML Bible which I have on > the shelf in front of me. I think it was dated as soon as it hit the > shelves. That's an important point - get something up to date so that you > aren't reading examples of code which the author expects might be valid in > the 0.0.2 release of some new protocol. This market evolves very quickly. 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. 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. Regardless, data format specs are typically backwards compatible. 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. > > Tony > > George Gallen wrote: > > ok. I've been given the task of trying to output a > > database based on an XML Schema file. (ONIX in > > particular), for edi purposes. > > > > I've played a little with XML, none at all with schema. > > So I'm looking for a some book titles that will help get > > me up to speed something of a reference, but also > > something starts you from scratch. > > > > If I need to buy two books, fine. 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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
