FreqSpec -> Recurrence migration, SX XML version rev

[Josh Sled]

Summary: The SX code is going to migrate from FreqSpec to Recurrence,
which will require a datafile version revision of SXes.


FreqSpec and Recurrence are really similar in capabilities, but
Recurrence has one extra feature which has been desired by SX users for
a while: last-weekday of the month processing.

I've been hoping for a while -- without delving too deeply -- that the
migration could occur by adapting the Recurrence in the object model
with the FreqSpec XML serialization ... the code would use Recurrence
objects, but read/write <sx:freqspec>'s back out; the datafile would be
compatible all the way back to gnucash-1.8...

This is still a possibility, I suppose.  The UI could intentionally
disallow last-weekday-of-month selection, only creating SX Recurrences
which are backward-compatible.  Pro: datafiles are good back to
gnucash-1.8, Con: users don't get the new feature.

I think the con outweighs the pro.  I'm planning on versioning the
<gnc:schedXaction> structure, and simply replacing the FreqSpec with a
Recurrence.

Note that the version number change is just the right thing to do, but
the 1.8/2.0 parsing code doesn't actually check the version number.  It
does, however, require that the <sx:frespec> is present, and thus will
fail when it is not.  The 2.2 code will be a bit better, I guess.

After the change, there's a lower-priority, nice-to-have-for-2.2 feature
of including a {File > Export > GnuCash 1.8/2.0} (or maybe a drop-down
in the {File > Save As...} dialog, or whatever).  But I don't consider
it a 2.2 release blocker.  If users do complain and/or need to go back
to 1.8/2.0 from a 2.2-saved datafile, we could also have a stand-alone
converter script (in Your Favorite Scripting Language) that did the job.
I don't really intend to do either before 2.2.


Notes for posterity...

Looking at the XML handling code, there's no good way to report the
location or type of error during parsing.  It looks like most code does
PERR and PWARNS.  It'd be nice to extend the code to at least say "error
parsing at line # col #, xpath {/gnc-v2/gnc:book/gnc:schedXaction}:
element sx:recurrence not recognized."  Or whatever.  But it's a fair
bit of rework to plumb the appropriate error/value handling through the
sixtp parsing stuff.

It wouldn't be *too* bad to support such a "save as specific version"
option.  The setting would need to be plumbed from the UI to the
backend, then from the backend through the "sixtp_gdv2" structure, and
then into the individual gnc_mumble_dom_tree_create(...) functions, most
of which have *no* context about the serializing effort.  Probably the
bigger issue/change would be a front-end check to make sure that the
content *can* be saved in a previous version, and maybe error-ing out or
resolving conflicts before (while?) doing the writing.

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070207/b2d5e9da/attachment.bin