Bug #483
closed
eml-entity changes needed
Added by Matt Jones almost 22 years ago.
Updated almost 22 years ago.
Category:
eml - general bugs
Description
Changes as decided upon at the Sevilleta EML meeting, April 24-25, 2002:
Responsible: Chad, Peter
0) name all entity types using camel caps (e.g., dataTable)
1) otherEntity stays in eml-entity module, others separate modules
2) entity types are: otherEntity, dataTable, dataView, StoredProcedure,
spatialImage, spatialGrid, spatialVector
3) expand names to use long names for all elements, including spatial types
4) add "spatialReference" module -- not sure how this will be tied to the other
spatial types
5) move "spatialRepresentationType" to the spatialRepresentation ComplexType
6) Possibly put connection info into the entity description, although I think we
decided against this by the end (putting it in resource instead)
Peter's notes include a mention of "change logs" which I don't understand. Peter?
Fixed the following sub parts of this bug: 0, 1, 3, 5
Notes on the others:
2) Added new modules for dataTable, spatialImage, spatialGrid, spatialVector
Left otherEntity and the shared spatial complex types in eml-entity.xsd
dataView and storedProcedure have NOT been created yet because I do not
have a model for them. Peter: please provide.
4) I'm not sure what goes in the spatialReference module. It has not been
created. Peter: please clafify.
6) I did not do anything with this because I think we decided in the meeting
to leave connection information elsewhere. If this is not the case, it
can be added later.
Other Notes: The documentation for all of the spatial entity types needs to
be updated. Peter, I think you are the best one to do this since you have
the best understanding of the models and the information represented therein.
Each of the new modules has it's own namespace which can be referenced
externally for importing types. Each module also has an implemented
element of the type defined in the module. That should be the only
free-standing element in the module.
I will leave this bug unresolved until the aforementioned problems are
addressed.
added eml-view and eml-storedProcedure. I did not add any documentation to
these modules. Peter, will you please do this or provide me with a textual
description of each element so that I can add the docs. thanks. Item 2 is now
done leaving only 4 and 6.
spatialReference is the module that describes a spatial dataset's projection
system (ie, how locations on a round surface are plotted on a flat plane)
I am working on revising and documenting the following modules:
spatialReference - setting short names to long ones, adding eml-doc.
spatialGrid - using chad's draft, adding eml-doc
spatialVector - using chad's draft, adding eml-doc
spatialImage - using chad's draft, adding eml-doc
"change log" referred to the element i had added to maintenance.xsd to provide
a history of changes to datavalues made since the release of a dataset. Our
conversation in Sevilleta got stalled on the question of whether you can ever
change a value in a dataset without forcing you to release it as a new dataset
(presumeably including a description of the changes in the protocol module).
So you may want to consider making a separate bug for this as it is pretty
unresolved.
Some comments:
the organization of eml-entity is confusing. Because it is largely used in
other modules, it desperately needs documentation to guide the user in
understanding where to use the simpleTypes, elements, etc. for instance,
coverage, physical, and protocol are all included in otherEntityType, but
there's no explanation as to why they were put in there. We understand that
they may apply, but it need to be explicit. Please add the docs when you add
elements.
coverage, physical, and protocol should be optional.
Why is LengthUnitCode in eml-entity? Not sure if this is just a pasted block
that needs clarification or removal...however, I may have missed it's point, too.
Changes completed and checked in to CVS.
Original Bugzilla ID was 483
Also available in: Atom
PDF