2008/6/17 Sam Johnston <>:
> And which part of what I said implied that this would not be the case? The
> point is to have the TC looking at a recent release, but to give them some
> room to move... tying them to the version available at launch time or
> release time is not really workable.
OK, I read your comment differently.
>
>>
>> To 'keep up to date' is the issue.
>> Suggest a request to the main TC to identify (change markup) all changes
>> to an existing document with each release such that this TC can
>> identify changes.
>
> So you want them to target multiple releases? If they have the bandwidth
> then all the better...
No. Just to make it easier for them to recognise changes in a changing spec
so they know where to work on updates.
This TC's work should track updates to the main spec.
>
>>
>> Another one would be to produce a version (xhtml) which had navigable
>> ID values to check tests against links to the standard.
>
> I've mentioned this in a previous thread too - even if the ToC within the
> spec document(s) are currently broken, the anchors themselves are there and
> can be referenced as I have in a number of my posts (you just have to view
> source to get them).
And the anchors are ... weak?
generate-id() would be an improvement.
The para number converted to an ID value would be better,
could be derived.
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
