[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: xml schema best practices question.. one big xml or lots o

• To: leevi@t...
• Subject: Re: xml schema best practices question.. one big xml or lots of little components?
• From: Peter Hunsberger <peter.hunsberger@g...>
• Date: Mon, 18 Apr 2005 08:57:24 -0500
• Cc: Michael Kay <mike@s...>, xml-dev@l...
• Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LcZVzdD4DItISP3qdpYZ2BjWanYj1dQSNixlMdt4dwc0/WOp5+BCEJs1vVepC0bO7x0G9YE6ygPL6TEkP4Kx3od121v1FTm7fLhut8fetSLhZCmxLDaFbWPdkcxsr97/Uduy86nD6288CZCHgOTvuRvdfJV3mexJRtJ4PhoYwlU=
• In-reply-to: <4260E031.8020502@t...>
• References: <200504160857.j3G8v1w0014934@e...> <4260E031.8020502@t...>
• Reply-to: Peter Hunsberger <peter.hunsberger@g...>

On 4/16/05, Leevi Graham <leevi@t...> wrote:
> thanks for your response michael,
> 
> it seems that after all my study and research into xml it is not the
> right form of storgae for the application i wish to create. The info
> would hopefully be accessed numerous times and as more people add their
> business details the xml file will become bigger.. So i guess that a
> relational database od the key afterall.
> 
> so now i am armed with this new information and clarity.. i have to ask
> what is xml good for??. If files sizes become a problem when accessing
> the information repeatedly what is a real world situation where xml is
> ideal? possibly storing seperate bits of data for occassional retrieval?

Joe gives you one good answer; transport between systems is a good fit
for XML.

The other place we use it is when we need to transform something into
many different output representations.  XML comes with a lot of good
tool kits for tree traversal and assembly and tree transformation,
(specifically parsers and XSLT.)   So, if you have problems where,
typically in the past you may have built a lot of procedural code to
manipulate your data, now-a-days you may find it easier to instead
output the data as XML (many RDB's will do that for you directly) and
use the tool sets to transform it.  Since some modern browsers can now
consume XML more-or-less directly, so when we talk transport and
transformation you should include taking the data to the browser and
displaying it in the equation.

The caveat here is that learning XSLT may or may not be easy for you. 
However, if you've got lots of this kind of thing to do I think the
learning curve is worth it.

> 
> i understand that xml is browser, computer, etc independent and that one
> of its key bebefits in extenability but what good is that if you cant
> share large amounts of data quickly and easily.. will native xml
> databases solve this problem?

Databases aren't designed for data "sharing" as much as they are for
data management.  Networks are where the rubber meets the road when it
comes to sharing.  As such, consider XML for the times when the data
isn't in a database.  Not that you should rule out native xml
databases, but if you're looking for a reason to use XML, start with
the easy stuff first: transport and transformation.

> as always one answer leads to a 1000 questions...

<snip/>

-- 
Peter Hunsberger

• References:
  • Re: xml schema best practices question.. one big xml orlots of little components?
    • From: Leevi Graham <leevi@t...>

• Prev by Date: [ANN] XmlVoyager: Hierarchical Tables (or Tabular Hierarchies)
• Next by Date: Re: xml schema best practices question.. one big xml or lots of little components?
• Previous by thread: Re: xml schema best practices question.. one big xml or lots of little components?
• Next by thread: Yet another survey: results and sample size (was: XQuery Adoption Survey Results)
• Index(es):
  • Date
  • Thread