Thanks, Mike for the answers.
There's a slight correction to the schema I wrote. The correct schema
fragment is below:
<xs:element name="price" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:attribute name="effective" type="xs:date" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
Just thought of writing this here, to make the archives useful.
On Mon, Mar 15, 2010 at 1:41 PM, Michael Kay <mike(_at_)saxonica(_dot_)com>
wrote:
Clearly one can always design a data model in which history is modelled
explicitly, but the idea with temporal database work has always been that
everything has history and the system should take care of it automatically
(rather in the way that CVS or SVN always allows you to find the state of a
file at a given time in the past). So Dana's proposal is essentially to
allow you to query the historical states of any given node, without you
having to do anything explicit in your XML design to keep the history as
part of the active document.
Her description of the model at the conference was very much a sketch, I
don't know how much detail is fleshed out in the paper.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
--
Regards,
Mukul Gandhi
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--