Bug #1662
openid key definitions in EML
0%
Description
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 <references> 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:
1. 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.
2. 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.
3. 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.
Files