Changes between Initial Version and Version 1 of Ticket #371, comment 5


Ignore:
Timestamp:
04.03.2015 20:15:58 (5 years ago)
Author:
jri
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #371, comment 5

    initial v1  
    1515  My rationale here is to avoid extending the `DeepaMehtaObjectModel` -- that is also the basis for JSON parsing -- by a "workspace" information. I want keep the object model small and see "workspace assignment" as a separate aspect. (Anyways, this might be seen as an implementation detail.) 
    1616 
    17 2. We could consider the quite different approach that is sketched out in the original ticket description. That is we could generalize the special meaning of the "magic `dm4` URI prefix" :-) and make a principle of it: expressing an object's workspace affiliation explicitly by its URI prefix. That would mean that DM maintains a global table that maps URI prefixes to workspace URIs, and that plugins can add entries to that table (either directly in the declarative migration or via `plugin.properties`). 
     172. We could consider the quite different approach that is sketched out in the original ticket description. That is we could generalize the special meaning of the "magic `dm4` URI prefix" :-) and make a principle of it: expressing an object's workspace affiliation explicitly by its URI prefix. 
     18 
     19  That would mean that DM maintains a global table that maps URI prefixes to workspace URIs, and that plugins can add entries to that table (either directly in the declarative migration or via `plugin.properties`). 
    1820{{{ 
    1921dm4: dm4.workspaces.deepamehta