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

RE: Healthcare and Security/Privacy

• From: Joshua Allen <joshuaa@m...>
• To: "'K. Ari Krupnikov'" <ari@i...>, xml-dev@l...
• Date: Mon, 24 Jul 2000 20:59:02 -0700

Probably most people here have seen it, but in 
case not, the book "Data on the Web" by Dan Suciu and
some others has a thought-provoking discussion
of how semistructured data like XML fits into
traditional ways of dealing with relational data,
theory around efficient access patterns, and more.
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=155860622X


> -----Original Message-----
> From: K. Ari Krupnikov [mailto:ari@i...]
> Sent: Monday, July 24, 2000 8:55 PM
> To: xml-dev@l...
> Subject: Re: Healthcare and Security/Privacy
> 
> 
> "W. E. Perry" wrote:
> > 
> > Jonathan Borden wrote:
> > 
> > > alternatively, one could wrap the filesystem in a 
> DOM/XPath accessor and let
> > > the filesystem code perform the access checks for you. I 
> think it would take
> > > less code to wrap the filesystem *BUT* one could always 
> munge Xerces to
> > > provide ACL behavior.
> > >
> > > My gut feeling is that using a filesystem designed for 
> lots of small files
> > > will give the proper level of concurrency and access 
> control. Which do y'all
> > > think would be the most efficient?
> > 
> > IMHO, this will have to be a DBMS, not simply a filesystem. 
> The underlying data
> > store (which for many reasons should be native XML) will 
> require an enclosing
> > engine to:
> 
> <...>
> 
> Add to this transactional integrity, referential intergrity 
> and caching
> that most RDBMSs (with the notable exception of MySQL, which in some
> ppl's oppinion is an SQL wrapper around a filesystem) provide 
> for free.
> 
> -- 
> K. Ari Krupnikov
> 
> DBDOM - bridging XML and relational databases
> http://www.iter.co.il
> 

• Prev by Date: Re: Healthcare and Security/Privacy
• Next by Date: Question About Namespaces and DTDs
• Previous by thread: RE: Healthcare and Security/Privacy
• Next by thread: RE: Healthcare and Security/Privacy
• Index(es):
  • Date
  • Thread