Re: [patch] removal of chiuldElement attributes in dispspec files

On Wed, 2004-10-13 at 22:11 -0400, Douglas Burke wrote:
> On Wed, 13 Oct 2004, David Malcolm wrote:
> 
> > On Wed, 2004-10-13 at 18:30 -0400, Douglas Burke wrote:
> > > The attached patch changes occurrences of
> > >
> > >   <header-info childElement="foo"></header-info>
> > >
> > > to
> > >
> > >   <header-info xpath="normalize-space(child::foo)"/>
> > >
> > > in the dispspec file since the code does nothing with the childElement
> > > attribute. I've also changed the DTD to remove the childElement attribute.
> >
> > Hmmm.... looks like the cong-dispspec-element-gxx.h was broken, and had
> > the attribute "tag" rather than "childElement" for this, which was meant
> > to initialise tagname; this failing would have caused failures in
> > cong_dispspec_element_header_info_get_xpath_expression
> >
> > So this got me thinking: should we fix childElement, or get rid of it?
> > Having two ways to do it felt overcomplex, so I decided to get rid of
> > it.
> >
> > So I've applied your patch to the dispspecs directory, and hacked out
> > the rest of the support from the dispspec loaders from the src
> > directory.
> 
> Some thoughts I have about the use of an XPath expression to "personalise"
> the title section of tags (i.e. the xpath element of the header-info tag
> in an element):
> 
> 1) How ofter should they be updated?
> 
> At present I don't think they are, which means you have to reload the file
> if you add/change the item the Xpath expression points to. However,the
> only safe way I can think of doing it would be to update all values after
> any document change (or at least re-evaluate them all to see if the value
> has changed). Which seems nasty.

Yes, there's a bug about this somewhere in BZ; can't find it offhand.
This could be really slow.  There's a class in the code for dealing with
an evaluated XPath expression (see src/cong-xpath-expression.c).  In
theory it can emit a signal whenever the evaluated expression changes. 

However, it's probably not complete, and I don't rememeber how much of
the rest of the code uses it.  We may be able to optimise things by only
calculating changes on a document end_edit, and perhaps having a time-
delay, so that it only bothers recalculating everything if the user
stops typing for a second?

> 
> 2) Examples where I find the use of XPath limiting
> 
> For a document containing something like
> 
>   <examples><example>...</example><example>...</example></examples>
> 
> I have xpath="concat('Number of examples = ',count(example))" for the
> examples tag. I would like each example tag to have an XPath expression
> which results in the text "Example <n> of <m>". It's easy to get the <m>,
> but not the <n>, via XPath. Or perhaps I should say I can't work out how
> to get the <n>.

I'm a little worried about cases like this from an i18n point-of-view:
do we expect translators do be able to deal with this?

> 
> Another case is that of conditionals; e.g. if there is a child element
> called title then use its contents, but if not then act as if there is no
> XPath expression.
> 
> 3) does it make sense to make the EXSLT functions in libxslt2 available
> for use in the xpath expressions?
Dunno - am too busy trying to break/fix Fedora Core 3 right now to look
into this properly, I'm afraid

> 
> Doug