OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [regrep] Object Relocation Vs. Object Export Facility

(Replying publicly to private message from David with his permission)

David RR Webber - XMLGlobal wrote:
A supplemental thought in the usability department.

If I have a bunch of stuff on screen that I want to associate
or otherwise point to in another registry, I can probably
figure out a GUI mechanism to allow me to quickly tag items
and then pull up a view in another registry and hit - associative
link to "this stuff here".

But what is happening under the hood?  I think creating the
links is all covered off in RIM today.   But if I then think - instead of
link - 
export the stuff I just tagged - and then import into the
remote registry underneath that classification - or even,
replicate classification and import as a chunk of content.

It's support for those actions that I'm wanting from the
user point of view since I've found that right now - when
I develop content in my "Test" environment - there is
no clean way to get it over to "Production".

Notice the issues revolve around "preserve UUIDs", as
opposed to create new UUIDs, and the choice of
either update all references to the old UUIDs with 
the new equivalent ones instead - so all
the content interactions are replicated across in the target
Excellent point David.

The issue of UUIDs is a very detail important. Do we need to support both use cases where:

1. the Exported/Imported objects retained their UUIDs  (needed for object relocation)

2. the Exported/Imported objects get new UUID assigned to them upon Import (needed for object copying like in a template)

(2) was not in the original use cases we considered.

To address (2) the easiest think would be to add a boolean attribute on SubmitObjectsRequest named "replaceUUID" with default of false. WHen true the registry where the data is being imported would replace all UUIDs for objects being imported with newly generated UUIDs.

This would allow the export facility to handle both use cases above.
I may be making this too complicated - but I'm just 
articulating issues I've found in working with what
we have today.

Thanks, DW.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC