Re: Style questions (2 questions)

Wendell Piez writes:
	
> Hi Rodman,

Hi Wendell,

>> <post @tag="reference xml"      href="..." />
>> <post @tag="reference xml xslt" href="..." />
>> <post @tag="reference html"     href="..." />
>> <post @tag="linux"              href="..." />
>> 
>> 
>> reference
>>    xml
>>       xslt
>>    html
>> linux
>>
>> each word is a folder w/ multiple bookmarks in them (ala. del.icio.us).
>> 
>> As I recursed into folders, it would have been nice to get all post(s)
>> that started with the current @tag.  With keys that would be fast,
>> without keys and w/XPath alone it was quite slow.

> I don't think I understand the question. If you're asking "are keys useful for
> things besides grouping things by associated values" the answer is certainly yes.
> In fact the classic use case for keys isn't for grouping at all, but to support
> cross-referencing in general.

Yes, I've used keys outside of grouping also.  To clarify, using the folder analogy above,
when I recurse into a folder I need to find all of my subfolders.  That means I need to get
all 'post' elements that *begin with* a string.  E.g. I open the reference folder and need
all @tag(s) that *begin with* "reference ".  That would be:
   <post @tag="reference xml"      href="..." />
   <post @tag="reference xml xslt" href="..." />  and
   <post @tag="reference html"     href="..." />

But you cant do that with keys ... can you?  Well you could if you chopped off the
@tag at the first space.  But then you could not use that key for : get me all @tag(s)
that begin with "reference xml ".  These folders may go 7 levels deep.  So if I
wanted to, I could declare 7 keys into the same key name.  But I found a better work
around; declare a key where use == folder depth :

   <xsl:key name="depth" match="post"
      use="string-length( @tag ) - string-length( translate( @tag, ' ', '' ) )"
   />

   <xsl:variable name="our-child-folders"
      select="key( 'depth', 1+$depth )[ starts-with( @tag, $current-tag ) ]"
   />

But its all these "work arounds" that seem to be caused by keys _only_ doing equality
comparisons.  I know the reasons for string comparison being only equality (alphabets,
locales, encodings, etc...), is the use of keys driven by the same reasons?

I guess I am just trying to understand keys a little better since they are so useful.

Thx to everyone who answered Q#1 and Q#2, this is a very helpful list ...
-- 
Rodman