Comments:

Flat Nested Threaded Embedded

Oldest First Newest First

Author	Thread:
davin.church	MSXML vs. Office 2003 XML Posted: Tuesday, October 10, 2006 12:56 PM (EST) Nicolai,   XML is a standard way of encoding data using descriptive "tags" in angle brackets.  It has definitions for HOW to do everything, but does not specify WHAT is in those tags.  So each application is free to make up any kinds of keywords and organization that it desires.  Consequently, Excel doesn't use the same keywords as Access which aren't the same as APL.Grid, etc.  Each application uses keywords differently.  That's why you can't get the Grid to talk directly to Excel.  It has nothing to do with "versions" of XML, per se.   Have you checked out my XML toolkit at <http://apldn.apl2000.com/downloads/APLWI+Downloads/APLWIUF/2335.aspx>?  It has facilities for changing XML data to and from nested APL variables, making them much easier for APL'ers to process, plus easy extraction and construction functions.  It also contains a linkage to MS's "translation" facility, which enables you to write a "program" (XSL) to convert one form of XML to another, in case you really have to move between Excel & the Grid object.  The documentation also has a decent introduction to XML in general, if that would be of any interest.
Nicolai.Ohm	MSXML vs. Office 2003 XML Posted: Sunday, October 15, 2006 6:16 PM (EST) Davin,   thank you for your response and the hint to your XMLTOOLS.W3 workspace. I run an Excel XML text string through your function  ParseXML, but I didn’t got an APL data array but an deeply nested text array.   I think my perception was wrong. I thought XML should facilitate data exchange between different applications (such as the APL grid and MS Excel) but essentially XML is proprietary for each application. So we have to stick to the old CSV (comma delimited) format to let the user get the data into our APL+Win applications.
Nicolai.Ohm	MSXML vs. Office 2003 XML Posted: Sunday, October 15, 2006 6:16 PM (EST) Davin,   thank you for your response and the hint to your XMLTOOLS.W3 workspace. I run an Excel XML text string through your function  ParseXML, but I didn’t got an APL data array but an deeply nested text array.   I think my perception was wrong. I thought XML should facilitate data exchange between different applications (such as the APL grid and MS Excel) but essentially XML is proprietary for each application. So we have to stick to the old CSV (comma delimited) format to let the user get the data into our APL+Win applications.
Ric.Sherlock	RE: MSXML vs. Office 2003 XML Posted: Sunday, October 15, 2006 9:02 PM (EST) Nicolai, My limited understanding (I'm sure others can provide a better and more knowledgeable explanation) is that XML does facilitate data exchange between applications formats - however that doesn't mean that it works automatically. If both data formats are fully defined by their DTD, then they are "fully documented" and it should be possible to create a conversion routine between the two. It will get more complicated if the fields and data types don't map exactly between the formats - the conversion routine would need to decide how to handle that. Hopefully that's sort of right! In terms of getting some Excel data from Excel to APL, I think that your final conclusion is probably pretty accurate - you're not forced to stick with CSV, but it will probably be much quicker/easier than developing the conversion routine using XML. Other options might be to use COM or even ODBC.
davin.church	MSXML vs. Office 2003 XML Posted: Monday, October 16, 2006 12:31 AM (EST) Ric's right, Nicolai...  XML does help transfer data between applications, but both ends need to be speaking with the same vocabulary.  Typically what this means is that you're trying to write a new program that talks to another existing application.  You'll know what the other application is expecting to give and get and you would then write your application to match that.  Getting two different applications (like Excel and APL.Grid) to talk means that you need to perform a translation between them.  There are different ways to do that, most notably by writing a "translation program" in either APL (easiest to do using my tools) or in XSL (the XML-standard translation language).   Yes, my tools turn XML text into an easy-to-process deeply-nested array, or back the other way if writing.  That's the data structure I was talking about - not just a simple matrix of data.  Basically, it turns all the XML logical data nesting into real APL nested variables that are easier to work with in APL.  If it's a simple structure then it's pretty easy to just extract the data out of it (especially with my XMLPath function).  If you don't want to handle the data yourself (even with my tools), then you can take another approach (such as CSV or XSL).   However, if all you're trying to do is get Grid data and write it out to an Excel file, then there's easier ways to do that.  Use my ^ExcelValues utility (from my FILES workspace) if you just want quick and simple data transfer.  You can talk directly to Excel via COM if you want fancier stuff.  But if you're just writing data, then read the Grid data into a matrix and call ^ExcelValues with the matrix as the left argument and the filename to create as the right argument.  The reverse process also works easily, and I use it all the time when my users send me data to be loaded into their system.   Does that help?