The initial implementation of timeline functionality was based on the idea that a single location would have a single datetime or datetime range during which it would appear when the timeline was manipulated. Working on actual projects, though, has made it clear that this is not sufficient; any given location must be allowed to have an array of datetime points or ranges, since (for example) people revisit the same location. The proposal for doing this is as follows:
Instead of making the location element itself datable, instead we allow child date elements inside it, each one functioning as the original dating attributes did, using @from-iso, @to-iso and @when-iso, with slash-delimited iso ranges allowed in all three attributes (although the initial proposal, like the current system, will do nothing useful with ranges in the first two, taking only the earliest date from the former and the latest from the latter -- future work may allow for some "fuzziness" functionality based on slash-delimited ranges).
Instead of a single from and a single to property in the output JSON for a Feature, there will instead be a property datetimes which will consist of an array of from and optional to items.
The timeline construction in the XSLT can be updated with a relatively minor change to the XPath for retrieving datetimes.
The JS handling the timelineChange event will need to be complexified a bit to handle checking each of the feature's array of ranges to see if it should be visible or not.
I think that's all we actually need to do, but we'll see.
The initial implementation of timeline functionality was based on the idea that a single location would have a single datetime or datetime range during which it would appear when the timeline was manipulated. Working on actual projects, though, has made it clear that this is not sufficient; any given location must be allowed to have an array of datetime points or ranges, since (for example) people revisit the same location. The proposal for doing this is as follows:
@from-iso
,@to-iso
and@when-iso
, with slash-delimited iso ranges allowed in all three attributes (although the initial proposal, like the current system, will do nothing useful with ranges in the first two, taking only the earliest date from the former and the latest from the latter -- future work may allow for some "fuzziness" functionality based on slash-delimited ranges).from
and a singleto
property in the output JSON for a Feature, there will instead be a propertydatetimes
which will consist of an array offrom
and optionalto
items.I think that's all we actually need to do, but we'll see.