Re: [U2] Building XML using the UV XDOM API functions
My biggest issue is with the poor state of the documentation. It does not allow me to easily obtain a good level of competency, which I think is needed to feel like I can be productive with a tool, and to feel that the tool is worth using. Once I got past the documentation and did a lot of testing, and raising cases with Rocket Software (the guys here in Australia should now know their XDOM backwards!), I have a much clearer understanding of what is possible and what the limitations are. Gregor, This is a good point and pretty important. When I approach a methodology like this and find that there is a lack of documentation then the question comes up. Do I spend the time to dig around to attempt to find enough documentation to make this tool usable? I consider using intrinsic tools the best choice, if the benefiit outweighs the cost. However if it is trivial to roll my own, or if there is an alternative extrinsic tool, then it is tempting to bail out. Availability of code examples (cookbooks, etc.), best practice guides, technical specs and so on, often determine which languages/tools I choose. Charles Shaffer Senior Analyst NTN-Bower Corporation ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
I'll have to disagree with you on this one Tony. As a vendor yourself you would of course think this way. As an end user of the product we would like it all to come from one source. This is the reason that Microsoft has got such a jump on everyone else, they will provide you with all of the tools as well as the database. I'm talking about the harsh reality of things, at one time if you went IBM you went all the way, now it's Microsoft. Companies don't want to deal with several vendors they want one. Jerry Banker -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Monday, October 25, 2010 11:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Building XML using the UV XDOM API functions Gregor, your comments serve as a testimonial to support my position against using many of these vendor-supplied toolkits. Some of them are OK, but many not. People insist on the DBMS vendors building stuff for them, but then we get the mess that you've described. For this reason I continue to recommend at least consideration for integration with tools that are outside of the DBMS. DBMS vendors should be focusing on making superior databases, not XML, web services, or a lot of this other fluff. People in the open source and commercial markets spend a great deal of time focused on these things, and because of this, their offerings are often much better. So take a look around and weigh other offerings against the built-in functionality. It would be nice to see people here comparing more toolkits - it might save others from feeling like they're stuck with whatever is provided by the DBMS vendors. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
Let's be careful we're lobbing grenades at the right enemy. As I see things the conflict here isn't choosing vendor supplied solutions vs. open source, the problem is the vendor doing a poor job of making something that is usable and truly useful. There is a time and place for both vendor supplied and open source solutions. As Jerry has stated some customers prefer to have one vendor for everything. For other customers, having one vendor for everything is a level of captive dependence they would rather avoid. One size certainly does not fit all. But all that aside, vendors need to put more attention into their products to make them useful and usable rather than simply another tick on a marketing checklist. Having XML support or whatever doesn't mean jack squat if it's so convoluted and unstable and poorly documented so as to be about worthless without heroics. This is where vendors could learn a great deal from the open source movement; open source technologies, though having no clear vendor or support often do a much better job of making things that are useful, usable, AND understandable. Once vendors return to a commitment to excellence over a commitment to marketing things may change. Until then, as solution providers the best we can do is keep all of our options open and when there are no options, to create new ones. -Kevin http://www.PrecisOnline.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
On 10/26/2010 1:46 PM, Kevin King wrote: But all that aside, vendors need to put more attention into their products to make them useful and usable rather than simply another tick on a marketing checklist. This conversation is reminding me of a recent blog post I read. http://blog.garlicsim.org/post/1388741380/thinking-of-your-software-as-a-butler-is-difficult-but ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
Brilliant article! Thanks for sharing. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
Right Jerry! As a VAR I have to support XDOM API. It took me hours to figure out how to do it. Because the API was poorly documented and any examples I found made no sense at all. When I got my code running the client could not use it because the version of Universe did not work with XDOM even though it was released with it. The key is tools. How many are still using AE or ED? How many think they are real productive using Notepad, EditPlus, AccuTerm's Editor, VI, wIntegrate's Editor, or whatever? The answer is most of you are using tools from the 80's and have no idea how productive you can be with new tools. I've been selling the equivalent of Visual Studio for U2 that runs on the Eclipse platform. I don't have to FTP and code from server to workstation. I can compile and format code with a click of a button. I can see subroutine code and includes just by hitting a single button. I have built an Universe and Unidata Editor, Dictionary Editor, Resize tool, Web Developer, Object Editor, U2 program and data installer, and ability to synchronize with version control. Our team built this wonderful Windows Explorer equivalent to copy files from account to account that saves me hours and hours when I have to have data to do testing on my machine or the client's test account. Maybe it is the Not Invented Here syndrome. See http://u2logic.blogspot.com/. Regards, Doug www.u2logic.com/tools.html -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jpb-u2ug Sent: Tuesday, October 26, 2010 10:48 AM To: 'U2 Users List' Subject: Re: [U2] Building XML using the UV XDOM API functions I'll have to disagree with you on this one Tony. As a vendor yourself you would of course think this way. As an end user of the product we would like it all to come from one source. This is the reason that Microsoft has got such a jump on everyone else, they will provide you with all of the tools as well as the database. I'm talking about the harsh reality of things, at one time if you went IBM you went all the way, now it's Microsoft. Companies don't want to deal with several vendors they want one. Jerry Banker ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
I actually like the XML handling built into UV. I have always been a believer in using the intrinsic facilities of the database where possible to maximise the performance of the process being automated. The XDOM API is a good example of this, and is a good fit for our requirements. My biggest issue is with the poor state of the documentation. It does not allow me to easily obtain a good level of competency, which I think is needed to feel like I can be productive with a tool, and to feel that the tool is worth using. Once I got past the documentation and did a lot of testing, and raising cases with Rocket Software (the guys here in Australia should now know their XDOM backwards!), I have a much clearer understanding of what is possible and what the limitations are. Which is why I created the blog and started adding entries for various aspects of the XDOM that were not obvious from the documentation. I just hope it helps others get a handle on the XDOM API a bit quicker than I did. It might also allow others to better evaluate the XDOM API as a valid toolset, rather than discount it out of hand due to FUD, or marketing pressures. Gregor -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Tuesday, 26 October 2010 3:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Building XML using the UV XDOM API functions Gregor, your comments serve as a testimonial to support my position against using many of these vendor-supplied toolkits. Some of them are OK, but many not. People insist on the DBMS vendors building stuff for them, but then we get the mess that you've described. For this reason I continue to recommend at least consideration for integration with tools that are outside of the DBMS. DBMS vendors should be focusing on making superior databases, not XML, web services, or a lot of this other fluff. People in the open source and commercial markets spend a great deal of time focused on these things, and because of this, their offerings are often much better. So take a look around and weigh other offerings against the built-in functionality. It would be nice to see people here comparing more toolkits - it might save others from feeling like they're stuck with whatever is provided by the DBMS vendors. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1AYrw4K3L1/76hLrBplQLdEzGQ20K2ljp/0 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
Compared to something like lxml it seems rather clumsy and unmaintained. On 10/26/10, Gregor Scott gregor.sc...@pentanasolutions.com wrote: I actually like the XML handling built into UV. I have always been a believer in using the intrinsic facilities of the database where possible to maximise the performance of the process being automated. The XDOM API is a good example of this, and is a good fit for our requirements. My biggest issue is with the poor state of the documentation. It does not allow me to easily obtain a good level of competency, which I think is needed to feel like I can be productive with a tool, and to feel that the tool is worth using. Once I got past the documentation and did a lot of testing, and raising cases with Rocket Software (the guys here in Australia should now know their XDOM backwards!), I have a much clearer understanding of what is possible and what the limitations are. Which is why I created the blog and started adding entries for various aspects of the XDOM that were not obvious from the documentation. I just hope it helps others get a handle on the XDOM API a bit quicker than I did. It might also allow others to better evaluate the XDOM API as a valid toolset, rather than discount it out of hand due to FUD, or marketing pressures. Gregor -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Tuesday, 26 October 2010 3:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Building XML using the UV XDOM API functions Gregor, your comments serve as a testimonial to support my position against using many of these vendor-supplied toolkits. Some of them are OK, but many not. People insist on the DBMS vendors building stuff for them, but then we get the mess that you've described. For this reason I continue to recommend at least consideration for integration with tools that are outside of the DBMS. DBMS vendors should be focusing on making superior databases, not XML, web services, or a lot of this other fluff. People in the open source and commercial markets spend a great deal of time focused on these things, and because of this, their offerings are often much better. So take a look around and weigh other offerings against the built-in functionality. It would be nice to see people here comparing more toolkits - it might save others from feeling like they're stuck with whatever is provided by the DBMS vendors. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1AYrw4K3L1/76hLrBplQLdEzGQ20K2ljp/0 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Sent from my mobile device ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
Hi Gregor Thanks for sharing your useful experiences and your blog. I found the same issue with U2 MQSeries API documentation too. Although, I guess when you are using such complex API's - it helps first to understand the underlying technology and concepts. Be it MQSeries or XML, etc. Otherwise, it is a case of learning or mis-learning two things at once. I find nearly all documentation from vendors have issues. Be they specialists in a particular field of a jack-of-trades multi-national software corporation. :) Your mileage will varyas it vary in respect with your own competency and the fact one size can never fit all skills/knowledge (etc)...be it tools or documentation or vendors or consultants! ;-) I do see value in investing some time/effort in the potential value that third-party tools and consultants can provide. Should budget, time and capabilities dictate such a requirement. Alas, we rarely have enough the later attributes... Cheers, David -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Wednesday, 27 October 2010 10:30 AM To: U2 Users List Subject: Re: [U2] Building XML using the UV XDOM API functions I actually like the XML handling built into UV. I have always been a believer in using the intrinsic facilities of the database where possible to maximise the performance of the process being automated. The XDOM API is a good example of this, and is a good fit for our requirements. My biggest issue is with the poor state of the documentation. It does not allow me to easily obtain a good level of competency, which I think is needed to feel like I can be productive with a tool, and to feel that the tool is worth using. Once I got past the documentation and did a lot of testing, and raising cases with Rocket Software (the guys here in Australia should now know their XDOM backwards!), I have a much clearer understanding of what is possible and what the limitations are. Which is why I created the blog and started adding entries for various aspects of the XDOM that were not obvious from the documentation. I just hope it helps others get a handle on the XDOM API a bit quicker than I did. It might also allow others to better evaluate the XDOM API as a valid toolset, rather than discount it out of hand due to FUD, or marketing pressures. Gregor -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Tuesday, 26 October 2010 3:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Building XML using the UV XDOM API functions Gregor, your comments serve as a testimonial to support my position against using many of these vendor-supplied toolkits. Some of them are OK, but many not. People insist on the DBMS vendors building stuff for them, but then we get the mess that you've described. For this reason I continue to recommend at least consideration for integration with tools that are outside of the DBMS. DBMS vendors should be focusing on making superior databases, not XML, web services, or a lot of this other fluff. People in the open source and commercial markets spend a great deal of time focused on these things, and because of this, their offerings are often much better. So take a look around and weigh other offerings against the built-in functionality. It would be nice to see people here comparing more toolkits - it might save others from feeling like they're stuck with whatever is provided by the DBMS vendors. T ** IMPORTANT MESSAGE * This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ** ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
It was definitely 'mapped' into our world. There are steps in the API that logically would never be used 'standalone', but as the underlying process broke the functions out as the underlying API did -- for example -- the PrepareXML must be followed by OpenXML -- why show that to us developers?!? We should have received a PrepareAndOpen function call instead. I mean, I will never do a PrepareXML that is not immediately followed by an OpenXML. It was a literal implementation of the underlying requirements without any thought to the 'target user'. Anyway, that kind of design ugliness was what said 'checkbox item' over 'well thought out' or 'implemented for real users' to me. I voiced this the first time I went through the process -- my point was that all parts of the systems handles that kind of 'allocation of memory' without it having to be explicitly executed. The XML add-on is the most C like stuff ever presented to us to use in BASIC! g So I'm in the camp that I like that it is built in to UniData, but it really was a cheesy (and maybe even inconsiderate) job on the design and implementation That was my take anyway! -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Tuesday, October 26, 2010 6:36 PM To: U2 Users List Subject: Re: [U2] Building XML using the UV XDOM API functions Compared to something like lxml it seems rather clumsy and unmaintained. On 10/26/10, Gregor Scott gregor.sc...@pentanasolutions.com wrote: I actually like the XML handling built into UV. I have always been a believer in using the intrinsic facilities of the database where possible to maximise the performance of the process being automated. The XDOM API is a good example of this, and is a good fit for our requirements. My biggest issue is with the poor state of the documentation. It does not allow me to easily obtain a good level of competency, which I think is needed to feel like I can be productive with a tool, and to feel that the tool is worth using. Once I got past the documentation and did a lot of testing, and raising cases with Rocket Software (the guys here in Australia should now know their XDOM backwards!), I have a much clearer understanding of what is possible and what the limitations are. Which is why I created the blog and started adding entries for various aspects of the XDOM that were not obvious from the documentation. I just hope it helps others get a handle on the XDOM API a bit quicker than I did. It might also allow others to better evaluate the XDOM API as a valid toolset, rather than discount it out of hand due to FUD, or marketing pressures. Gregor -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Tuesday, 26 October 2010 3:35 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Building XML using the UV XDOM API functions Gregor, your comments serve as a testimonial to support my position against using many of these vendor-supplied toolkits. Some of them are OK, but many not. People insist on the DBMS vendors building stuff for them, but then we get the mess that you've described. For this reason I continue to recommend at least consideration for integration with tools that are outside of the DBMS. DBMS vendors should be focusing on making superior databases, not XML, web services, or a lot of this other fluff. People in the open source and commercial markets spend a great deal of time focused on these things, and because of this, their offerings are often much better. So take a look around and weigh other offerings against the built-in functionality. It would be nice to see people here comparing more toolkits - it might save others from feeling like they're stuck with whatever is provided by the DBMS vendors. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1AYrw4K3L1/76hLrBplQLdEzGQ20K2ljp/0 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Sent from my mobile device ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users
[U2] Building XML using the UV XDOM API functions
I have recently been involved in a project that gave me my first chance to get acquainted with the UV XDOM API functions. gripe I must say that I was bitterly disappointed with the documentation on the XML functionality in UniVerse 10.2. Nothing more than a simple description of each of the API functions, and no clear example of how to go about getting started. Not to mention the inter-weaving of UniData and UniVerse configurations that lead me into much confusion about what was going on. /gripe Once I got a handle on how things worked, it was obvious that if we were to be building XML docs in code, we would need to create some supporting code to make things easier. I ended up creating a function to add new elements and attributes that made a huge difference. I used a function instead of a subroutine because it fits in easier with the XDOM API function calls, and this makes it easier to adopt. I created a description of the function and its implementation over at http://gdoesu2.wordpress.com/2010/10/25/an-easier-way-to-build-xml-in-universe/, in case anyone else needs a helping hand getting started with manual XML document building. The site also has a few other entries on the quirks/features of the XDOM API functions which might be of interest as well. Regards, Gregor This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Building XML using the UV XDOM API functions
Gregor, your comments serve as a testimonial to support my position against using many of these vendor-supplied toolkits. Some of them are OK, but many not. People insist on the DBMS vendors building stuff for them, but then we get the mess that you've described. For this reason I continue to recommend at least consideration for integration with tools that are outside of the DBMS. DBMS vendors should be focusing on making superior databases, not XML, web services, or a lot of this other fluff. People in the open source and commercial markets spend a great deal of time focused on these things, and because of this, their offerings are often much better. So take a look around and weigh other offerings against the built-in functionality. It would be nice to see people here comparing more toolkits - it might save others from feeling like they're stuck with whatever is provided by the DBMS vendors. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
