I probably should have worded things differently.  Much of my experience
has been in the automotive arena, where I have seen a lot of "non-standard"
things done, and where I have seen a lot of code almost purposely written
to make that person "indispensable" (either that or they were just a kid in
the nursery banging on the round hole until the square peg finally went
through).
And getting them to change that when you are the small guy, and, they are
the big guy is not reality.

Not that I consider myself above everyone else in that industry (because I
have met a lot of intelligent folks too)- I have just seen a lot of
code/systems that could have been done better, if patience and some thought
had went into it.  (This is including working with xml feeds in the
automotive industry).

So at any rate...

In short:

If I were to compare for example, php's simple xml "tools" with U2 xml
"tools", I would consider the php tool more flexible, and easier to learn.
 (perhaps "tools" is a wrong term to use...)

http://php.net/manual/en/book.simplexml.php

That statement would agree with your statement of using tools outside of MV.

That being said, everyone has tools they like, and some companies mandate
you use certain tools within a department, etc.

So if you have to use U2 xml tools, then by all means.  BUT, if you can
find another tool (or build one yourself), that is more flexible, easier
for others to understand, and gets the job done in a way where its also
maintainable by others (i.e. not jamming that square peg in there), then do
that.

And at this point, Mark (the original poster) has probably stopped paying
attention which is totally my fault.  I apologize.


On Fri, Jan 27, 2012 at 12:39 PM, Tony Gravagno <3xk547...@sneakemail.com>wrote:

> From: John Thompson
> > This is where I think languages like php get it right.
> > Their simple XML stuff makes it simple to parse even
> > the junk you may get from somewhere else.
>
> I've commented here and blogged on this topic a number of times.
> I shake my head at the pain people continually subject themselves
> to when trying to force the square peg of XML into the round hole
> of Pick BASIC just because that's the comfort zone.  There are
> any number of other tools out there specifically designed to work
> with XML.  If you go to many other forums, developers aren't
> focused on the XML processing.  They deftly convert to/from XML
> (and JSON) without a problem, and their questions are largely
> focused on what to do with the data.  MV professionals need to
> shift focus from doing everything within the MVDBMS to making the
> best use of all tools available and integrating the MVDBMS with
> whatever utility does the job that's required.  At the core of
> it, even when using external tools we convert XML to "something"
> and that "something" ultimately needs to be saved in an MV
> structure.  (Similarly for outbound XML.)  But if you're focused
> on namespaces and attributes then the tools you're using aren't
> providing adequate abstraction from the XML, and you might want
> to consider tools that convert XML to "something else" which is
> easier for you to use.
>
>
> > The reality is, that there are a lot of sites and
> > places out there that will send you all kinds of xml,
> > and I found that since I was not proficient at
> > "massaging" those "non-standard" feeds into what the
> > U2 xml tools wanted, I just found it easier to do it
> > another way.
>
> Whoe - stop right there.  I tend to angle away from DBMS-oriented
> tools for processing XML, but in all fairness we can't expect any
> tool to behave properly if the data doesn't conform to standards.
> No, I haven't seen "a lot of sites" sending "all kinds of XML"
> that is "non-standard".  If you have a trading partner that
> doesn't produce or consume industry-standard documents, you need
> to talk with their IT people, and escallate to management on both
> sides if you're not getting cooperation.
>
> Respectfully, I'm guessing you're just not familiar with some of
> the details of XML, and when the U2 tools don't seem to address
> one of those details I'm guessing you're considering the document
> to be non-standard rather than the U2 tools.  Again, in all
> fairness to the U2 team, I'm guessing this is a documentation
> issue or some lack of understanding along the way rather than any
> entity being non-standard.  If indeed the U2 tools aren't
> providing standard functionality, well, see paragraph 1 above.
> :)
>
> Good luck.
>
> Tony Gravagno
> Nebula Research and Development
> TG@ remove.pleaseNebula-RnD.com
> Nebula R&D sells mv.NET and other Pick/MultiValue products
> worldwide, and provides related development services
> remove.pleaseNebula-RnD.com/blog
> Visit http://PickWiki.com! Contribute!
> http://Twitter.com/TonyGravagno
> NEW! http://groups.google.com/group/mvdbms/about
>
> _______________________________________________
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>



-- 
John Thompson
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to