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

Re: XML too hard for programmers?

  • To: xml-dev@l...
  • Subject: Re: XML too hard for programmers?
  • From: rog@v...
  • Date: Mon, 24 Mar 2003 23:19:50 0000

Re:  XML too hard for programmers?
aslom@c...:
> you could have some database abstraction layer to make this to happen
> automatic when you change any part of document (this layer could also
> transparently handle slicing XML input into fragments that are stored
> and modified independently to minimize need to re-indexing).

I don't think that would be possible in general.  In particular, it
wouldn't be possible in my case, as the indexing was to speed up
page-based access to an Ebook; the addition of a word to a paragraph
at the start of the document could alter the page boundaries for the
entire document.

In general, I found processing XML in bounded space quite hard.  I
only succeeded in bounding the space used in certain common cases, but
this could easily be thwarted unintentionally.

In my case, for example, I was trying to bound the space requirement
to that required by the elements displayed on the current page.

Problem is, given code like:

	e_head(p: ref Parser, i: ref Item.Tag)
	{
		p.down();
		# call functions to add layout to display page
		# depending on the XML they encounter
		while ((t0 := nexttag(p)) != nil) {
			case t0.name {
			"title" =>
				e_title(p, t0);
			"link" =>
				e_link(p, t0);
			"style" =>
				e_style(p, t0);
			}
		}
		p.up();
	}

there is always the possibility that one of the functions we're
calling fills up the current page, in which case we must stop
processing immediately and return.

It's then difficult to go back to where we were before: we have marked
the XML parser's state, but we can't "freeze" the state of the e_head
function for future resuscitation, unless the implementing language
provides a feature that allows a process to externally store a
continuation of itself (mine doesn't).

This leaves only one option: implement the entire thing as a push-down
automaton...  which loses all the "nice-looking-code" advantages we
just gained!

In the end, I indexed only elements that appeared at the top nesting
level, which did cover all the documents I found, but would have been
thwarted by someone putting <div>...</div> around the whole thing.

Maybe someone else on the list has encountered these kinds of problems
before and has a nice solution?

  cheers,
    rog.


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.