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

On Fri, 15 Oct 2004, David Malcolm wrote:

> 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?

The bug is #123012 - so http://bugzilla.gnome.org/show_bug.cgi?id=123012

I think only updating on an "end_edit" makes sense.

> >
> > 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?

Well, I'm only using it for in-house documents, so I do not need to worry
:-). Maybe we turn the xpath attribute into a child of header-info and
pick the translation based on the lang attribute (or something). IANAIS (I
am not an il8n specialist) ...

> >
> > 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

No bother. I was just thinking random thoughts aloud.

Doug