We wanted to expose dspace's metadata in a way that can be used by other applications. They are nice restfull urls that are actionable and easily predictable. There are a few themes that will do client side parsing of those urls in javascript, it opens the possibility for other things to be created. That's not a big argument for handles over internal identifiers, remember manakin is several years in the making and during the most of the design cycle dspace's independence from handles was nothing but a pipedream with no one really working on it.
As a side note about the protection of Metadata. The DSpace API's data model says that all metadata for any item (withdrawn or in progress) is visible to any anonymous user. In general the dspace model is all objects are visible, but may not be actionable or some parts may be restricted. In my opinion the API should return an authorization errors for attempting to access metadata on restricted items, and then perhaps we could set some kid of security permissions on metadata fields either in the registry or through some dspace.cfg parameter. Although the xslt on the pipelie is a pretty easy hack that solves your problem and is way easier to implement.... Scott-- config On Jul 8, 2008, at 5:46 PM, Mark Diggory wrote: > > I'm still tempted to suggest that those xslt's should be using / > internal/metadata/handle over /metdata/handle... scott can you > comment on why this isn't always the case? > > -Mark > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
