[Home] [By Thread] [By Date] [Recent Entries]

  • From: Ihe Onwuka <ihe.onwuka@g...>
  • To: "Costello, Roger L." <costello@m...>
  • Date: Sun, 22 Nov 2015 14:33:36 -0500



On Sun, Nov 22, 2015 at 12:47 PM, Costello, Roger L. <costello@m...> wrote:
Hi Folks,

Assertion: Accessing/manipulating element nodes is simpler, easier, and faster than accessing/manipulating text. An element-based data model is better suited to XML's strengths than is a text-based data model.


<snipped/> 
    

use this as your data model:

        <living-room>
            <you/><are/><in/><the/><living-room./>

Problem no 1. Although you might get away with the full stop you are going to run into punctuation characters that you can't have in an XML element name? 
 
            <a/><wizard/><is/><snoring/><loudly/><on/><the/><couch./>
        </living-room>

and use the former only for presentation.

Do you agree?


In XPath 2.0 it is no great hardship to do a delimited tokenize to generate elements if you  wish so your arguments in favour look a bit anaemic. 

Now I have walked this walk before. 

In order to minimize XML payload size and get  indexing for free in eXist I  came up with the idea of representing the keywords tagged to a movie with an element

<movie>
  <drama/>
  <romance/>
</movie>

 rather than 

<keyword>drama</keyword>
 <keyword>action</keyword> 

or the denormalised <keyword>drama action</keyword>

eXist was having none of it as they have a limit on the number of distinct element (or is it node) names you can have in a database which I very quickly blew and my data wouldn't load.

I ended up coming to  the conclusion that a graph database was a better fit for what I was trying to accomplish.






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member