Peter,
>At 17:23 18-05-2001 -0400, Richard Knapp wrote:
>>Would it be helpful to put a naming convention on the IDs? What I am
>>proposing is this: adding a specific prefix to an ID to....
>I guess there's really two types of IDs to consider - one is the "name" of
>the instance of the entity we are dealing with, such as the name of a
>particular survey, and the other is its internal "record ID" which...
The ID in this instance would be the same as a primary key in a RDB.
>Database "wisdom" says that record IDs (keys) should not contain any data,
>but just serve to uniquely identify each record, i.e. a simple integer is...
True. And adding some "intelligence" to the field is not an approved means of handling the situation.
However, when given a list of IDs without any type of key it is rather difficult to determine which ID
relates to which entity.
>different sources, and we do *not* want to have a central control for
>issuing unique record IDs, UISIC has proposed a scheme for a minimal format...
Interesting point. If there are two CaveXML files both with a Station GUID of "00001" (or for that matter,
to Caves with ID "00001"), how is this to be resolved if they turn out to be part of the same system... or
are combined for viewing by another user?
>own IDs without risk of duplicating any one else's. You can see it at:
>
>http://rubens.its.unimelb.edu.au/~pgm/uisic/exchange/exchprop.html
Sounds like namespaces. I'll give it a read. Thanks for the reference.
>This format does not include a component which identifies the entity-type
>to which the record belongs, e.g. a survey record ID would look the same as....
Do you mean querrying the parent Element for it's ID and type? Hmmm... That makes sense.. unless
you are using a generic XML editor. There would be nothing to help guide the user to the correct ID. On
the other hand, there is nothing to restrict the user - in that instance - from providing any ID they feel is
appropriate.
>can identify the entity-type from its context. This scheme has been
>successfully used in the Australian national cave database which includes a
>range of entities (caves, maps, refs, people, organisations,...).
In this example, is there a single point from which IDs are issued? There won't necessarily be one - as
you previously mentions - for CaveXML. There is still the problem of conficting IDs.
>Also, I guess I should really be calling this record ID an "instance ID",
>because particularly when using XML the idea of a "record" becomes rather...
or an "Element ID" since it is a reference to an element. Either gets the point across.
You've raised some interesting points and more questions.
- Element IDs _can_ be unique through a single CaveXML file and serve a similar function to RDB's
Primary Key;
- There is no reason to designate special ID codes in relation to their element type;
- ID collision is still an issue, especially when combining files of different Caves;
- Namespaces might provide some resolution to the ID collision problem.
- It might be helpful to have somewhere in the spec about the contents of the ID.. in addition to the XML
spec. (ie. length and content) Maybe something like [0..9]8 meaning the ID should be numeric with eight
digits.
- How will Caves put together from separate CaveXML files be addressed and IDs resolved?
- How will Namespaces resolution be provided? User specified or system?
Does that about cover it?
- Richard Knapp
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2b30 : Mon Sep 03 2001 - 06:00:00 CEST