SitePoint Sponsor

User Tag List

Page 3 of 6 FirstFirst 123456 LastLast
Results 51 to 75 of 142
  1. #51
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by timvw
    That is true for every data format you use (Assuming you document it as good as you would do with the XML format)
    Perhaps the best of XML is that now there are existing parsers for it in almost every language. It wasn't the case several years ago.
    For example. In my current project I write a Java application, that is going to output XML files for web use with PHP, Java, JavaScript, etc.
    If I used some other format, I should write the parsers myself .

  2. #52
    SitePoint Guru momos's Avatar
    Join Date
    Apr 2004
    Location
    Belgium
    Posts
    919
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    XML is just the easiest way to multiple platforms and multiple languages, and as an extra plus you can save relationships inside of them. It will not replace databases in big systems, but for very small systems it is the ideal database.

    It's due to its simplicity that people love to adopt it and marketing helped popularising it ofcourse (XHTML, XForms, SVG, RDF). And XSLT made it versatile, what is not to love...

  3. #53
    SitePoint Enthusiast
    Join Date
    Jun 2004
    Location
    London
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Plain XML is hierarchical, which means that all related elements must be nested within the elements there're related to.
    When processing XML, an element isn't actually complete until you reach its end tag.
    If an application is parsing and XML document into elements in memory before transferring them into another
    persisted form of data, this means that the elements that contain other elements must be retained in memory
    until their internal data members are processed.
    This results in some fairly significant strain on memory use, especially with larger documents.

    RDF does not require this nested structure, RDF/XML you can associate two seperate XML structures with each other
    though a Uniform Resource Identifier (URI) with the URI you can link one XML structure to another without having to
    embed the second structure directly within the first.

    davro
    David Stevens, create-inspire
    PHP London, www.phplondon.org

  4. #54
    SitePoint Addict
    Join Date
    Feb 2004
    Location
    belfast
    Posts
    386
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    What is wrong with CSV for data for data exchange?
    Haha, was reading another thread and came across this as a sig:
    Quote Originally Posted by pippo
    "Any fool can write code that a computer can understand.
    Good programmers write code that humans can understand."M.Fowler
    I think this says it all.

    Also, just noteing ... SVG is one area where XML is playing big - just look at Adobes support for this format.

    From what I know google maps uses XML along the same lines as SVG.

    I'd say adopting a DB architecture for that app would have been very difficult to implement.

  5. #55
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by REMIYA
    Perhaps the best of XML is that now there are existing parsers for it in almost every language. It wasn't the case several years ago.
    For example. In my current project I write a Java application, that is going to output XML files for web use with PHP, Java, JavaScript, etc.
    If I used some other format, I should write the parsers myself .
    Hehe, i said that already in #14

    Quote Originally Posted by momos
    XML is just the easiest way to multiple platforms and multiple languages, and as an extra plus you can save relationships inside of them. It will not replace databases in big systems, but for very small systems it is the ideal database.
    Why would it be the ideal database?

    How would you handle n-m relationships in XML?
    How would you handle transactions and concurrency with XML?
    How about performance? How do you declare constraints? And how do you enforce them?

  6. #56
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "Any fool can write code that a computer can understand.
    Good programmers write code that humans can understand."M.Fowler
    No because Martin Fowler is talking about code, we are talking about data. There's a big difference! In fact the data we are talking about is meant to be created and read by computers as exchange format, no human should ever need to read it. So there goes your argument.

    Quote Originally Posted by REMYIA
    I've never said XML is meant to be a replacement for a database. But it can be used like one.
    And I never implied you said that.

    Quote Originally Posted by arborint
    I think there is a difference between "is meant to be" and "can be used as".
    You are right about that I guess.

    But it may indicate a demand, which may in turn might mean that people find it useful (whether you do or not).
    XML is a buzzword, that explains the demand.

    There certainly cases where being able to talk to a database directly using XML would be easier than converting back and forth.
    Of course if you use XML in other parts of your application, it is easier to talk to a database with it. But then the question arises (again) why did you need to use XML in your application in the first place.
    I once had a problem.
    I thought: "Oh, I know: I'll just use XML!"
    Now I had two problems.

  7. #57
    SitePoint Guru momos's Avatar
    Join Date
    Apr 2004
    Location
    Belgium
    Posts
    919
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sorry for being a bit hasty, with small I meant 1 person-can-edit-more-people-can-read-from-it, so concurrency/transactions would not be an issue.

    and for the n-m thing:
    <a>
    <b></b>
    </a>
    <a>
    <b></b>
    <b></b>
    </a>

    constraints become simple business-logic.

    They've did it once in the firm I work for, for a customer of ours, and it worked like a charm.

  8. #58
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    XML is a buzzword, that explains the demand.
    Not more than my name (Dr Livingston) is a buzzword in my view Xml is not a new technology, it's been around for a number of years now, and it's pretty much been taken as second nature.

    To explain the demand however, for Xml, you need to understand the underlying technologies that use it, from SAX to Web Services, etc. This is why Xml has far more advantages over and above what CSV could ever offer.

    I'm not saying CSV is obsolete, it isn't (well, not quite yet anyways) but it's a changing world, and Xml takes presedence, doesn't it?

    Plus it is trivially imported into all data manipulation software like databases and spreadsheets.
    Well that is true, but so much so, the same can be said of Xml, and I'd even go as far as saying that Xml has wider application usage, as suggested for example, SVG being one such application

  9. #59
    SitePoint Addict
    Join Date
    Feb 2004
    Location
    belfast
    Posts
    386
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    No because Martin Fowler is talking about code, we are talking about data. There's a big difference! In fact the data we are talking about is meant to be created and read by computers as exchange format, no human should ever need to read it. So there goes your argument.
    My understanding of XML is that it provides a way to describe data. By providing a description you inadvertently make it human readable.

  10. #60
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    XML has one very big minus.
    The characters used in the element tags may be only ASCII characters. That makes XML discribe data only for the English aware.
    What about the rest of the world

  11. #61
    Web Design Ireland cianuro's Avatar
    Join Date
    Jun 2004
    Location
    Dublin Ireland
    Posts
    914
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jplush76
    the most basic use of XML is for two systems to understand the same piece of data
    For me, that was the best basic explaination ever. Its quite difficult to get a head around what XML is initially.

  12. #62
    SitePoint Guru Galo's Avatar
    Join Date
    May 2005
    Location
    Holland!
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by REMIYA
    XML has one very big minus.
    The characters used in the element tags may be only ASCII characters. That makes XML discribe data only for the English aware.
    What about the rest of the world
    Isn't this why they invented Encoding ?

    Standard XML works with Unicode which is a character hash that contains maximal 65536 characters, for each character there are two bytes reserved this means that all characters from western, asian, greek and Russian languages can be displayed, it's just the Encoding format you choose that will decide what characters whould be displayed and what not

    Check on http://www.unicode.org/ for more information.

    The point is when i would use encoding="UTF-8" signs like "" and "" would indeed cause error's, however would u use encoding="ISO-8859-1" you could use them without errors so it is posible....

    edit : "" is a ISO-8895-15 character , sorry
    Business as usual is off the menu folks, ...

  13. #63
    SitePoint Guru Galo's Avatar
    Join Date
    May 2005
    Location
    Holland!
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cianuro
    For me, that was the best basic explaination ever. Its quite difficult to get a head around what XML is initially.
    Dont forget the Structure that is holding the data, it's not about the actual concrete data, data often comes from directives who refer to a piece of data which eventualy comes from a database, the structure XML presents is relevant, the data can come from anywhere, even a simple text file.

    I tend to see XML as a IL (Intermediar Language) so different systems can talk the same smalltalk
    Business as usual is off the menu folks, ...

  14. #64
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by momos
    and for the n-m thing:
    <a>
    <b></b>
    </a>
    <a>
    <b></b>
    <b></b>
    </a>
    Actually, this is 1 - n. Each a-node can have multiple b-nodes.


    Quote Originally Posted by momos
    constraints become simple business-logic.
    So basically, you're moving away from a database to some immature storage system.. In that case i would advise to use a dbms to handle the data, and simply write a tool that can import/export XML from it.

  15. #65
    SitePoint Zealot
    Join Date
    Feb 2003
    Posts
    156
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Galo
    Standard XML works with Unicode which is a character hash that contains maximal 65536 characters,
    No, the Unicode standard defines slightly less than 100.000 characters at the moment. And even the older Unicode 3.1 (?) which IIRC is a requirement for XML covers more than 90k already.

    for each character there are two bytes reserved
    This is UTF-16 you are talking, which is one possible way of encoding Unicode characters (and even UTF-16 may use more than 2 bytes depending on whcih characters it is encoding). XML processors must also understand UTF-8 which is a variable-lenght encoding (usually 1-4 bytes).

    this means that all characters from western, asian, greek and Russian languages can be displayed, it's just the Encoding format you choose that will decide what characters whould be displayed and what not
    That's the way it was before unicode came along.

    But with unicode you don't have to choose, one of the advantages of unicode is that you can display all languages on the "same page".


    But to get back on topic: Yes, it's a Good Thing that XML supports unicode. And with the option to add this metadata inside the file, probably saved some people an headache already.

  16. #66
    masquerading Nick's Avatar
    Join Date
    Jun 2003
    Location
    East Coast
    Posts
    2,215
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So i've read this thread, and still don't exactly understand, what is the advantages of storing data in a XML file rather than a database? Because if you use a XML file it is more easily accesable to other programing languages?
    Nick . all that we see or seem, is but a dream within a dream
    Show someone you care, send them a virtual flower.
    Good deals on men's watches

  17. #67
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ronanmagee
    My understanding of XML is that it provides a way to describe data. By providing a description you inadvertently make it human readable.
    My understanding is that XML is a simple text format.

    It appears XML is usable as a text container (human readable data) because the availability of tools for generation/parsing of XML is widely available..

    As soon as you want to use it as a binary data container you will meet it's limits. You would have to encode it (fe: base64), which makes it not very efficient.

    Imho, this limitation makes it hard to use XML as a database. Another important issue is that it will take a (serious) while before XML can compete with the current DBMS products out there (efficiency/speed/query optimization)

    XML can be very useful as a container for textual data coming from/going to a database (or any other text processing program). XSL comes in handy if you want to transform the data into something else. XQuery allows you to perform queries on XML. This may have it's uses, but usually you would already select only the data you need (fe: SQL where clause, before you generate XML from the resultset.)

  18. #68
    SitePoint Addict
    Join Date
    Feb 2004
    Location
    belfast
    Posts
    386
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by timvw
    My understanding is that XML is a simple text format.
    Although this is not a thread for deciding what xml is/is not, in my mind a simple text format is more akin to a csv file. With xml you can have complicated structures for data but more importantly you have data that describes data, something that xml was first introduced for.

    As for encoding DB's, require this as well, esp when storing images, albeit they do this in a much more efficient manner than xml currently, they still suffer from similar draw backs.

    What advantges do I see of XML:
    It can be deployed on a much simplier architecture and doesnt need any updating or patching unlike RDBMS

    Ability to transfer data between systems, mainly web based - RPC, eBooks with ability to publish to pdf etc.

    Validation - DTD/STD

    Disadvantages:
    Lacks the functionality more advanced features of DB have i.e. sql language and its ease of use, backup options, referential integrity

    Not suitable for really large projects - mightn't be the best idea to dump 100,000 customer records into an XML file and run xPath.

  19. #69
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ronanmagee
    Not suitable for really large projects - mightn't be the best idea to dump 100,000 customer records into an XML file and run xPath.
    No arguments on that

  20. #70
    SitePoint Guru Galo's Avatar
    Join Date
    May 2005
    Location
    Holland!
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by R. U. Serious
    No, the Unicode standard defines slightly less than 100.000 characters at the moment. And even the older Unicode 3.1 (?) which IIRC is a requirement for XML covers more than 90k already.

    This is UTF-16 you are talking, which is one possible way of encoding Unicode characters (and even UTF-16 may use more than 2 bytes depending on whcih characters it is encoding). XML processors must also understand UTF-8 which is a variable-lenght encoding (usually 1-4 bytes).

    That's the way it was before unicode came along.

    But with unicode you don't have to choose, one of the advantages of unicode is that you can display all languages on the "same page".

    But to get back on topic: Yes, it's a Good Thing that XML supports unicode. And with the option to add this metadata inside the file, probably saved some people an headache already.
    100.00 or 65.536.... alright you win
    Anyway, my conclusion is that you DO have to use an encoding to display specific characters, and yes it CAN use more then 2 bytes but never less.
    But that's not the topic indeed , i say go for XML, XML is joepie
    Business as usual is off the menu folks, ...

  21. #71
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ronanmagee
    Although this is not a thread for deciding what xml is/is not, in my mind a simple text format is more akin to a csv file. With xml you can have complicated structures for data but more importantly you have data that describes data, something that xml was first introduced for.
    http://www.w3.org/XML/. From the Introduction:

    Extensible Markup Language (XML) is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere.
    Quote Originally Posted by ronanmagee
    What advantges do I see of XML:
    It can be deployed on a much simplier architecture and doesnt need any updating or patching unlike RDBMS
    You will have to update/patch your tools to generate/parse XML too. And advantage you might experience, when you change your tools, you can easily convert your internal (==xml) format to a different format (using xsl). For a regular dbms this might be harder..


    Quote Originally Posted by ronanmagee
    Validation - DTD/STD
    It can be a pita to agree on a good DTD/XSD for your XML data. Look at the format for the propagation of your blog and the pile of RSS/RDF/Atom formats

  22. #72
    SitePoint Guru momos's Avatar
    Join Date
    Apr 2004
    Location
    Belgium
    Posts
    919
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Actually, this is 1 - n. Each a-node can have multiple b-nodes.
    <a>
    <name>fruit</name>
    <b>apple</b>
    <b>tomato</b>
    </a>
    <a>
    <name>vegetables</name>
    <b>tomato</b>
    </a>

    fruit has multiple items, but tomato is a fruit and a vegetable (True, there is replication, but it is many-to-many)

  23. #73
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But there still aren't b-nodes that hold multiple a-nodes..

    Anyway, as i've been thinking about it, assuming there is a n-m relationshop between a-nodes and b-nodes, you can represent n - m relationships by introducing a set of ab-nodes. But an XML schema (DTD/XSD) alone doesn't allow you to specify the constraints.

  24. #74
    SitePoint Guru hgilbert's Avatar
    Join Date
    Dec 2004
    Location
    London
    Posts
    839
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I am not an advocate for XML.
    But if all fails - I try XML/XSLT

    Often I find it can help reduce complexity
    You extract data (xml) from presentation (xslt)
    The output is then (xhtml).

    I should have an example very soon.

    I was struggling with classical ASP because the business logic was way too complex.
    .NET Webforms are not very accessible.
    So I found best to generate an xml and resolve it via an xslt.
    Then Response.Write the resulting xhtml.

    It's just another tool not a buzzword


  25. #75
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,629
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    As for the handling and storage of data within your own application, there are a few (but very few) reasons in my experience to employ XML to retrieve data and move it around. That is the job of your database. Someone mentioned (can't remeber if it was this thread or another)... the benefit of simply moving XML files should your app move to another platform. Well, if you have your database access layer properly abstracted from your business logic... this is pretty much a non-issue.
    I would argue the opposite. At least with languages outside of PHP (eg things with application servers and memories longer than one request).

    First, you have to store your database configuration somewhere outside of the database. XML is as good an option as any, especially given the plethora of easy options to serailze and deserialize it from and into objects. All your DBAL has to do is go look for ./config/db.config and it is a very real possibility to have a self-configuring database. That is but the tip of the iceberg. It is usually much easier, especially insofar as deployment goes, to edit text files to get something flying rather than have to get the application to allow you to login to the content manager before configuring things.

    That said, I do agree that using Xml as the persistence medium for most projects is a waste. If it makes sense anywhere, it is in the single-user, desktop application space where it eases deployment significantly, as one need not install a database engine with the application. Nor one need not write their own as most DOM-based parsing libraries are more capable than any DBMS you can cook up in a reasonable amount of time. The main issues are concurrency issues, which single user, desktop applications do not suffer from nearly as badly as web applications.

    The place where Xml shines in the CMS space is communications between disparate systems and creating generic inter-process messaging. One project I am working on involves re-architecting a half-dozen web properties, none with remotely similar back-ends, to share much of the same data. Rather than ripping out all of them and completely replacing the back-ends, we are setting up some XML/Webservice based messaging systems to make the applications talk in real time.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •