| Re: Change from xml:id to UUID in future? [message #1315 is a reply to message #1309] |
Thu, 05 March 2015 08:26  |
nicolas.gatez
Messages: 1
Registered: March 2015
|
Junior Member |
|
|
Dear all,
I'm Nicolas Gatez, from the belgian IM Infrabel, and member of the
<infrastructure> <topology>
modelling group.
My opinion is also that the UUID, while strongly recommendable, is not
always the best solution,
especially when dealing with legacy source systems where UUIDs are not
supported or
implemented.
It would lead to run-time/export-time generated UUID, meaning that the
same object would have a
different UUID each time a new extract is created.
so, on top of the "Fake persistence" problem, it would also add a problem
of "fake variability",
where you will never know if you see a different object or the same
object with a changed ID.
However, when designing a new system it is always best to ensure that the
used primary keys
are "as unique as possible", for which UUID seems a sound solution.
So, I reach the same conclusions, UUIDs should be allowed, and even
recommended when
possible, and xml:id (which i see as the legacy system id) could be used
when UUIDs are
impractical.
However, ids still have to be unique within the scope of one file/extract.
Best regards,
Nicolas.
--
----== posted via PHP Headliner ==----
|
|
|
|
Members
Search
Help
Login
Home
