mbjones
commented
7 years ago Original Redmine Comment Author Name: Peter McCartney (Peter McCartney) Original Date: 2004-09-01T21:34:38Z
I checked in changes to eml-resource.xsd and buildDocbook.xsl as a proposed fix to some of this bug. The fix introduces an optional system attribute to the references element, which corresponds to the existing system attribute accompanying the id element through out EML. if used, it qualifys that the matching id pointed to by the references tag has a scope defined by the system attribute. Thus, EML documents can contain more than one id attribute with the same value provided that they are scoped with different system attributes. Changes to the "reusable content" section reflect this. if system is defined, it must be defined for both the target and the referencing element and it must match. Otherwise it must be absent from both.
I think there is still some ambiguity in the wording of the docs that could benefit from some additional input. the eml root has an attribute called scope which is "document" by default and "system" by option. We now allow there to be more than one system referenced. if system tags are used once, does this mean they must be provided in all cases? or, can i write an eml where the ids for attribute are document scope, but the ids supplied for literature cited are scoped to a particular system? Do we really need the "scope" attribute? if it is left as default, is it invalid to use the system atrribute anywhere in the document?
Author Name: Peter McCartney (Peter McCartney) Original Redmine Issue: 1662, https://projects.ecoinformatics.org/ecoinfo/issues/1662 Original Date: 2004-08-26 Original Assignee: Matt Jones
there are several problems emerging with the unique key definitions in eml. in eml.xsd, there is a key definition that requires all instances of the @id attribute to be unique within the document. when content is to be duplicated there is to be one instance of the content with an id assigned and all other instances are to use the tag to point to that id. id's in a
document may be declared as document or system scope, meaning that they are
declared to be unique only within the document or within a broader naming
authority that is identified in the @system attribute.
Here are some of the problems:
there no enforced unique constraint on the @system attribute, although it is implicit. Thus it is possible to create a dataset element usint an id with system=cesdataset and a creator with system=asupersonnel. when those systems have each assigned a similar value, you get conflicts. to avoid them, users are forced to change identifiers and break the pointers back to the original source of the content.
the spirit of the id and references tags was to insert some degree of normalization that xml inherently lacks. however, it can be a rather arbitrary choice with in the document which instance is the one that gets the content and which ones get the reference pointer. This makes it very difficult for people trying to write tools to edit eml documents since one could easily drop an element that contains elements that contain content that other elements are pointing to. This gratuitously complicates programming for EML and is likely to discourage potential contributors of tools for working with the standard.
EML method allows you to embed the eml of related datasets that were used to produce the current one in the methods discussion. conflicts can arise between the identifiers of the embedded datasets. attemping to resolve conflicts between documents using references could mean you have to edit those documents rather than embed them.