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

Re: One ID per Element Type - why?

  • From: Toby Speight <Toby.Speight@s...>
  • To: "XML developers' list" <xml-dev@x...>
  • Date: 06 Apr 2000 10:55:33 +0100

one id
Steve> Steve DeRose <URL:mailto:Steven_DeRose@b...>

[Sorry for the delay in responding - I've been out of action for a
while due to being at home with a broken ankle.  It's recovering now,
and I'm catching up on XML-DEV.]

0> In article <v03110702b500e3dd7f85@[209.244.212.214]>, Steve wrote:

Steve> However, there is no principled hard reason that using CDATA
Steve> attributes makes anything slower -- that's a property of a
Steve> particular implementation.

Agreed.  Don't consider only run-time speed, though - code size
is important, as it directly impacts development time and ease of
maintenance.  If your environment provides a facility (in my
example, ID-based hyperlinks in DSSSL), think carefully before
deciding to re-implement it in a different way.

What I'm *not* saying is that the decision should always fall on one
side of the line or the other - there are many points to consider.


Steve> It sounds as if the one(s) you're thinking of keep a table or
Steve> index specifically for IDs, but do not keep a table or index
Steve> for CDATA attributes.

Possibly - the DSSSL spec makes no constraints on how its functions
are implemented.  It's more an API specification in this respect.  But
one of the things it requires is a function to retrieve an element by
ID, so most implementations do this more quickly than brute-force
searching.  There's no reason to expect fast lookup of arbitrary
attribute values, though, so most implementations don't index all
attribute values.


Steve> For dealing with non-trivial-size documents, there is much to
Steve> be said for indexing a lot more than IDs.

Agreed.  How you do this depends on your environment, of course.  If
you've a large body of work, you probably want to use more specialised
tools (my corpus is only a few hundred kilobytes, so I index in the
same process).  I'm not sure how this is supposed to be related to the
issue of IDREFs and linking, though.

In my own indexing, the indexes are sorted collections of index terms
with IDREFS attributes pointing at the occurrences of the terms, so
perhaps it's relevant for that reason?


Steve> I'm not sure what you mean by 'correct linking'; there's not
Steve> reason a grove implementation can't rapidly retrieve the
Steve> element whose MY-CDATA attribute has some particular string
Steve> as its value.

Simply that the grove has links from the referencing attributes to
the target elements, usable by the `referent' function in DSSSL, or
equivalent in other languages.

-- 


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

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.