[Home] [By Thread] [By Date] [Recent Entries]
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.
Proof by example:
Case 1: Retrieve "west"
Text-based data model:
<edge>garden west door home</edge>
XPath to retrieve "west":
substring-before(substring-after(., ' '), ' ')
Element-based data model:
<edge>
<garden/>
<west/>
<door/>
<home/>
</edge>
XPath to retrieve "west":
*[2]/name()
Clearly, retrieving "west" in the element-based data model is simpler, easier, and faster.
Case 2: Retrieve a range of data items (2nd to 3rd data items)
Text-based data model:
<edge>garden west door home</edge>
XPath to retrieve the desired range of data items:
tokenize(., ' ')[position() = (2,3)]
Element-based data model:
<edge>
<garden/>
<west/>
<door/>
<home/>
</edge>
XPath to retrieve the desired range of data items:
*[position() = (2,3)]/name()
Clearly, retrieving a range of data items in the element-based data model is simpler, easier, and faster.
Of course, at the point of presentation we will want to convert the element-based data model to a text-based data model.
Recommendation: Separate the data model from presentation details and make data models element-based.
Let's take a dramatic example. Rather than this:
<living-room>
you are in the living room.
a wizard is snoring loudly on the couch.
</living-room>
use this as your data model:
<living-room>
<you/><are/><in/><the/><living-room./>
<a/><wizard/><is/><snoring/><loudly/><on/><the/><couch./>
</living-room>
and use the former only for presentation.
Do you agree?
/Roger
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |

Cart



