[
https://jira.duraspace.org/browse/DS-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21205#action_21205
]
Mark Diggory commented on DS-815:
---------------------------------
> I'm definitely coming round to the "raise an exception at construction" POV.
> Validation in the UIs would be very nice, but separately it should not be
> possible to create a "date" object which is not a date. If a
> UI wants to throw away information then it may, but there is no reason for
> >the object not to provide information in any case,
> unless that information (in this case, -1 or an Exception) would cause
> significant problems. We can improve the UIs later and the
> information will already be available when we do.
At least an exception could be easily caught and its message describe the
problem for the user. Thus the UI/application could use that detail to assist
in alerting the user, thats an appropriate application activity. But the
validation itself would best be in the MetadataValue. I will look into this in
the DSpace DOmain Model changes too.
> We probably also want a curation task to ferret out busted "dates" already
> lurking in the repository. And to document that certain
> fields must contain ISO 8601 dates (to some precision) and nothing else.
Sounds like a good idea
> Miscellaneous temporal intervals should not be claimed to be "dates". The
> code depends on these values to work like dates. If
> people want to enter "17--" or "the middle ages" then coverage seems to be
> the right place for such. I understand that
> sometimes the best we have is "written circa 1066" -- if we want to represent
> that then DCDdate could (as a separate
> improvement request) be augmented with something like
> setIUncertain(boolean)/isUncertain() and still compare like a definite
> date (ignoring the "uncertain" flag but still obeying granularity).
I think the confusion arises in the perception that "2011" is a range from
2011-01-01 to 2011-12-31 and thus everyone thinks that the field can support
ranges (or somehow should). BEcause the database field is a varchar, they can
get away with it. I'd rather avoid complicating the DSpace MetadataValue API.
I'm already not too impressed with all the confidence stuff that was added by
the Authority Control work.
I feel very strongly we need to find a means to separate "System" and "User"
data more cleanly for the benefit of both parties. This means that we isolate
"bundles" of metadata fields, "system", "provenance", "administrative",
"descriptive". This will allow us to isolate metadata that needs consistency
for the system to operate properly from those descriptive and administrative
fields that curators and submitters want to fill out.
> If someone would like to propose a definite date as the meaning of new
> DCDate("") and new DCDate(null) then those could
> continue to be accepted.
Is there anywhere in the code (other than a possible empty/null database value)
that a "" or null would be passed to this class? I've not seen any
> The problem we really have (beyond the NPEs) is that we need certain fields
> to be definite dates (to some granularity) for
> purposes of comparison (browsing, sorting, filtering) while submitters need
> to be able to express indefinite or subject-specific
> temporal boundaries. Adding decade, century, millennium, and perhaps era
> (BCE/CE and the like) granularity to DCDate might
> help, but values put into those fields on which we do computations still
> need to conform to some syntax that we implement so
> that they can be compared.
That what coverage should be for, DCMI even has a value syntax for expressing
coverage ranges. It would be great to have some Submission Form composites that
supported this feature.
> DCDate throws NullPointerException with mangled dates
> -----------------------------------------------------
>
> Key: DS-815
> URL: https://jira.duraspace.org/browse/DS-815
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API
> Affects Versions: 1.7.0
> Environment: CentOS 5.4 with OpenJDK 64-Bit Server VM (build
> 1.6.0-b09, mixed mode)
> Reporter: Àlex Magaz Graça
> Assignee: Mark H. Wood
> Attachments: DCDate_test_mangled_date.patch
>
>
> DCDate.get*() methods throw a NullPointerException if the object has been
> constructed with a wrong date like "[17--?]" (DCDateTest patch attached):
> java.lang.NullPointerException
> at org.dspace.content.DCDate.getYear(DCDate.java:298)
> at org.dspace.content.DCDateTest.testDCDateString(DCDateTest.java:301)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> It makes the browse by issue date fail in JSPUI.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
