On 4/22/05, M. David Peterson <m(_dot_)david(_dot_)x2x2x(_at_)gmail(_dot_)com>
wrote:
I also chose to
dump the date processing template to help empahsize that the best way
to handle XML in this case is to ...
Hmm .. not sure what you were about the write there, but the date
processing for bibliographic processing -- as I said in the last
message -- is complex. And it's even more complex in the XML
documents I'm using. All of the followong can represent a date:
mods:originInfo/mods:dateIssued
mods:relatedItem/mods:originInfo/mods:dateIssued
mods:relatedItem/mods:part/mods:date
And the content is not only uncontrolled in the schema, but is messy
in the real world. All of these are valid:
2000-10-13
2000
2000-10
... and that doesn't even cover stuff like "October 10, 12-14, 2000"
or "Spring/Summer 2000".
So maybe the function needs to stay?
:-)
Bruce
--~------------------------------------------------------------------
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>
--~--