Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Learn XML Expand / Collapse
Author
Message
Posted Wednesday, May 02, 2012 10:44 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 8:20 PM
Points: 32,764, Visits: 14,928
Comments posted to this topic are about the item Learn XML






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1294340
Posted Thursday, May 03, 2012 12:27 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Wednesday, April 09, 2014 11:34 PM
Points: 6,996, Visits: 8,409
for those interested, you can still download the free ebook The Art of XSD By Jacob Sebastian at the Redgate books section:

http://www.red-gate.com/community/books/art-of-xsd


Johan


Don't drive faster than your guardian angel can fly ...
but keeping both feet on the ground won't get you anywhere

- How to post Performance Problems
- How to post data/code to get the best help


- How to prevent a sore throat after hours of presenting ppt ?


"press F1 for solution", "press shift+F1 for urgent solution"


Need a bit of Powershell? How about this

Who am I ? Sometimes this is me but most of the time this is me
Post #1294361
Posted Thursday, May 03, 2012 2:04 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Thursday, April 03, 2014 1:55 AM
Points: 87, Visits: 174
XML is a solution looking for a problem. The big mistake is thinking that data interchange is the problem. I have a data file to send that has two formats available, csv and xml, one is quick and easy to write, export and import as the format and schema are well documented and produces a file of about 4MB. The other is slow to produce, difficult to code and the schema is hard to understand, it is also slow to import and produces a file of about 22MB. You've guessed it the first is a CSV and the second is XML.

Data exchanges do not need to be human readable, they need to be machine readable, and for that small and fast are key, even EDIFACT is better than XML.

This doesn't mean I haven't learnt it, one day it will find the problem it is looking to be a solution to.
Post #1294391
Posted Thursday, May 03, 2012 5:06 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 3:35 AM
Points: 319, Visits: 2,151
Alex Gay (5/3/2012)
XML is a solution looking for a problem. The big mistake is thinking that data interchange is the problem. I have a data file to send that has two formats available, csv and xml, one is quick and easy to write, export and import as the format and schema are well documented and produces a file of about 4MB. The other is slow to produce, difficult to code and the schema is hard to understand, it is also slow to import and produces a file of about 22MB. You've guessed it the first is a CSV and the second is XML.

Data exchanges do not need to be human readable, they need to be machine readable, and for that small and fast are key, even EDIFACT is better than XML.

This doesn't mean I haven't learnt it, one day it will find the problem it is looking to be a solution to.


I think you are missing other real life requirements:

* Seamless extensibility (without needing rewrites of consuming processes)
* Serving multiple audiences with one XML stream instead of having to tailor for each and every consuming party

Data exchage between N:M party relationships is common and favors XML. And I found coding "adaptors" to import various data streams more error prone in CSV then for XML (I have to do both often). Granted, processing simple streams of simple types is faster in CSV, but when you have more complex data to convey (data with hierarchical structure), XML easily wins in the speed, compactness and ease/speed of processing and coding.

There is one real problem I experience with XML …. is people! Many people producing code that generates XML have no clue what they are doing, but it is that easy to produce! They are unable to model their data properly and often do not handle escaping well, causing errors in individual elements. But XML escaping is extremely simple and requires only a few find/replace actions you can do in practically every programming environment. It is truly a lack of basic knowledge that is the culprit here. I developed a toolset to work around the encoding issue by dropping those specific objects of interest that have these errors and keep processing the rest of the document.

So, the author of the article is correct….learn it, XML in its basic form is very easy to understand and not all that hard to navigate. And if you want to see a nicely formatted readably XML document for debugging purposes, just open it with Internet Explorer (provided the file is not humongous).
Post #1294484
Posted Thursday, May 03, 2012 6:14 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Sunday, February 23, 2014 8:23 AM
Points: 30, Visits: 163
Not to detract from XML, but from a programmer's perspective you better also learn JSON as well since some databases (MongoDB, CouchDB, Persevere) and services/frameworks are leaning in that direction instead of XML since it is more compact and you may have to write/use apps/services that parse XML to JSON and vice versa.

It's all relative to the size of your programming/database staff and how many hats you are required to wear in a day of course.



"There is nothing so useless as doing efficiently that which should not be done at all." - Peter Drucker
Post #1294511
Posted Thursday, May 03, 2012 6:52 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, April 04, 2014 8:42 AM
Points: 598, Visits: 1,504
Acconding to some of the local gurus, having Extended Events in XML makes it harder to build automation and parsing scripts, since you never know exactly what "fields" you need to plan for...So you can semi-automate the process.

Post #1294545
Posted Thursday, May 03, 2012 7:27 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Today @ 7:14 AM
Points: 1,465, Visits: 4,262
XML is good for exchanging data at the application level, but it's not very efficient for data storage in the database or exchange between two databases. That's why most DBA's are unfamiliar with it. In those situations where a DBA does confront XML, for example when an application is serializing objects in the database, it usually within a negative context; for example CPU spikes and bloated data storage. Most DBAs would rightlyfully rather be dealing with tabular data in relational tables.
Exposing things like extended events to the outside world as XML makes a lot of sense, but there are tools (like SSMS itself) that will do the work of parsing the tags and presenting it in a visual form. An XML document that contains complex objects like query execution plans or SSIS packages (.dtsx files) may be human readble when opened in Windows Notepad or XML Notepad, but really there is no reason for a DBA to be digging into it the tags, unless he's debugging something or just curious. I've resorted to poking around in XML documents myself on occasion; searching for connection strings or even manually fixing some property value that I had no luck resolving within the SSIS package editor. However, XML is self explanatory, there really is not much to learn. Knowing XSDs or XSLTs are not really required to read the underlying XML.



"Winter Is Coming" - April 6, 2014
Post #1294589
Posted Thursday, May 03, 2012 7:34 AM


Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Wednesday, April 09, 2014 8:22 AM
Points: 685, Visits: 2,992
peter-757102 (5/3/2012)
They are unable to model their data properly and often do not handle escaping well, causing errors in individual elements. But XML escaping is extremely simple and requires only a few find/replace actions you can do in practically every programming environment. It is truly a lack of basic knowledge that is the culprit here. I developed a toolset to work around the encoding issue by dropping those specific objects of interest that have these errors and keep processing the rest of the document.

Indeed, as an XML novice I found escaping an extremely annoying and frustrating task. (This was to produce XML to be read by PHP for displaying on a website.) In addition, I couldn't find an easy way to write out XML from SQL to a file with an included XML header, so I have used a rather clunky work-around.

Would you have any good links/references about how to handle this?

Thanks,
Rich
Post #1294597
Posted Thursday, May 03, 2012 8:21 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Thursday, April 10, 2014 1:08 PM
Points: 721, Visits: 1,264
charles.byrne (5/3/2012)
Not to detract from XML, but from a programmer's perspective you better also learn JSON as well since some databases (MongoDB, CouchDB, Persevere) and services/frameworks are leaning in that direction instead of XML since it is more compact and you may have to write/use apps/services that parse XML to JSON and vice versa.

It's all relative to the size of your programming/database staff and how many hats you are required to wear in a day of course.



I agree with you, Charles. I, too, am a developer. I see the importance of XML; it is used in a lot of situations and services. But JSON is very strong; perhaps stronger than XML, at least for transferring data over the wire.



Kindest Regards,

Rod
Post #1294641
Posted Thursday, May 03, 2012 8:28 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 3:35 AM
Points: 319, Visits: 2,151
rmechaber (5/3/2012)
peter-757102 (5/3/2012)
They are unable to model their data properly and often do not handle escaping well, causing errors in individual elements. But XML escaping is extremely simple and requires only a few find/replace actions you can do in practically every programming environment. It is truly a lack of basic knowledge that is the culprit here. I developed a toolset to work around the encoding issue by dropping those specific objects of interest that have these errors and keep processing the rest of the document.

Indeed, as an XML novice I found escaping an extremely annoying and frustrating task. (This was to produce XML to be read by PHP for displaying on a website.) In addition, I couldn't find an easy way to write out XML from SQL to a file with an included XML header, so I have used a rather clunky work-around.

Would you have any good links/references about how to handle this?

Thanks,
Rich


There are several ways, but so far I only had to generate XML from the application layer and not SQL. Once you know how and when to escape data, the problem is reduced to nothing more then concatenating strings in a natively efficient manner when using this method. For SQL specifically there are other ways as well, some likely more efficient (and complex), but I got no experience with them.

You could start with SELECT and the FOR XML clause for simple set representations in XML, but the output does not necessarily match what you need to generate (XML works case sensitive for example).

Documentation for the FOR XML clause: http://msdn.microsoft.com/en-us/library/ms190922(v=sql.100).aspx

As for exporting data to a file, that is something I found always lacking from T-SQL. Importing is easy and has fairly good support, exporting not so...it would be my number one wish for any new release! I hate DTS and any such overly complex replacement and just expect to be able to specify an output file in my SQL clause and be done with it (for the sake of both sanity and efficiency).

I assume you know the 5 characters that you need to replace? (this forum did not allow me to post them as it generated an error)
Post #1294652
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse