Aaron--
You don't have to convince me of the dangers. I have ugly memories of watching
Ross Wayland and Thorny Staples being chafed by the straightjacket of strong
integrity for objects/bdefs/bmechs that was baked into the 2.x series. {grin}
With time, though, I've forgotten the grim images enough to reprice in my mind
the guarantees that such strong constraints buy. But that's only my situation,
and I accept your narrative and its import and the cautions they imply.
Let me suggest the existence of a set of categories of repository behavior
desirable by different users, categories that might be directly connected with
scale. The cost of correcting a failure that is publicly visible (e.g. a
dissemination that fails) is often in a direct relationship with some function
of the size of the repository. It may be that such a cost is very high to some
users (who would then prefer to work in that comfortable, stylish, and
supportive straightjacket) but a marginal and uninteresting item to others (who
find it confining).
I'm impressed by Scott's suggestion of parameterized validation behavior, and I
wonder if we could imagine partitioning his proposed CMA validation flag
further into a module or service to include some of the options we've been
discussing, and perhaps others. Could we leverage some of the enhanced content
model validation functionality to support a range of sizes of straightjacket?
{grin}
While I understand and accept that forcing every user to construct workflows
that fulfill these kinds of integrity would be wrong, I believe that there are
enough users who would really benefit from the workflow feedback and long-term
stability that such integrities provide that it's worth considering such
provision.
---
A. Soroka
Digital Research and Scholarship R & D and Online Library Environment
the University of Virginia Library
On Oct 29, 2010, at 4:32 PM, Aaron Birkland wrote:
>
>> The CMA is such a core part of the repository architecture that I think a
>> situation in which the repository can be said to be working but the CMA
>> can't be is a bad situation to enable.
>
> Ah, I see your perspective. "working" is a bit of a sticky point here.
> In conceptualizing the CMA, here were a few thoughts or principles that
> motivated its design:
>
> - Users may choose to ignore the CMA - simply preserving and providing
> access objects without an explicit model is a valid use case.
>
> - The core repository is not concerned with referential integrity of
> RELS-EXT relationships.
>
> - There shall not be a prescribed order in which objects must be
> ingested into the repository.
>
> - Service binding will occur dynamically. If this cannot happen for
> some reason (missing objects, relationships, etc), then a runtime error
> is reported.
>
> These thoughts were partly in response to problems encountered with the
> precursor to the CMA. In particular, the precursor *did* enforce a kind
> of referential integrity - and this turned out to be a bit of a sore
> point. In response, there was a trend to more lightweight and dynamic
> behaviour.
>
> So, in other words, it was intentional that the core repository would be
> capable of ingesting and preserving objects that don't yet contribute to
> a functioning CMA behaviour. I think it was viewed that higher-level
> validation, correction, etc could occur later (if at all), or as part of
> some other functionality on layered on top of the basic core and enabled
> separately.
>
> Perhaps somebody can give more on the history and motivation. It could
> be worth revisiting if the resulting behaviours are seen as generally
> unintuitive.
>
>> It's not obvious to me how feedback could be supplied to avoid that, but
>> perhaps the ingest method could continue without the additional validation
>> of a) but could provide a response notation like "Ingested with PID",
>> "Ingested as content model with PID", "Ingested as service definition with
>> PID", etc. for the system-defined models? It could even be extended to
>> user-defined models, which could provide valuable feedback in a workflow.
>> But admittedly, that would induce more complexity and even if carried out
>> cleverly, might break older fragile installed workflows...
>
> That is an interesting line of thought.
>
> -Aaron
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Fedora-commons-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Fedora-commons-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
