Re: Some suggestions for documentation

[Nigel S. <nig...@us...>]

> > > hm, I can see that being able to update all the nodes in a set with
one
> > > instruction is useful, but why getDataParts and not any of the other
get
> > > functions?
> >
> > getData() calls getDataParts(), so getData() takes a xPathQuery.  Have
> > updated the source...  Which other "get" functions are missing this?
>
> I was using your list, Nigel. getDataParts was the only one of the
retrieval
> functions on it.

Ok, and which other get functions do you want xPathQuery access to?  Perhaps
there are reasons, but at the moment there doesn't seem to be a concrete
example for me to comment on, and I'm too busy/lazy to research it.  All I
have to go on is "any of the other get functions".

> > > On a related issue, could you add the ability to set the source
encoding.
> >
> > Ummm I don't really know where to start in coding this feature, as I
don't
> > really understand what's required.  It does sound like a useful addition
> > though, as I know we have many european users.  It's not an issue that
is
> > directly affecting me, so I'm afraid it's unlikely that I will look into
> > this with any sort of priority.  Don't suppose anyone else wants to?
Sam?
> > Peter?
>
> see xml_parser_create
> add parameter to this statement (in, erm, importFromString), and then
there
> would have to be some way of setting it to utf-8 or us-ascii (in case
anyone
> actually uses that). Because you can pass the constructor the filename,
you
> would have to pass this in as a param. Or of course not allow it here, but
> only with importFromString, and have a separate function to set before
> calling that.

Sounds like you know what you are talking about.  Looking forward to seeing
your patch ;o)

Cheers,

Nigel