talk@lists.collectionspace.org
WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org
View all threadsRe: [Talk] adding fields to core schema repeatable groups
Sounds good, Dan, and thanks for the quick response.
I completely understand the resource issue, and am glad it is coming up now,
since Megan et al. are reviewing priorities with the Mellon and IMLS
partners, for the rest of the schedule.
It sounds to me like we need to surface this work as a user-story
(admin-story?) that can be considered in the mix of things remaining.
Have copied Megan so she can coordinate this, or delegate as appropriate.
As to the technical issues you bring up on representation:
I think the macro-slot idea is a nice one. I am not clear how it works when
the macro repeats within a repeating block (a list of complex type), and the
fill refers to elements within a repeating block (a list of complex type).
In the services layer, we need to declare both lists as repeating complex
types, which is why I described the mux/demux model. If you come up with a
better way that we somehow accommodate, am happy to oblige.
If need be, I can sketch some xsd fragments for the services piece of this,
or you can just review:
http://fisheye.collectionspace.org/browse/~raw,r=4244/collectionspace/src/se
rvices/trunk/services/collectionobject/3rdparty/nuxeo-platform-cs-collection
object/src/main/resources/schemas/collectionobjects_common.xsd, and see the
titleGroupList and titleGroup complexTypes. As I had envisioned the support,
we would need a corresponding pair of complexType definitions in the
domain/local schema(s).
Thanks - Patrick
-----Original Message-----
From: Dan Sheppard [mailto:dan.sheppard@caret.cam.ac.uk]
Sent: Wednesday, March 02, 2011 10:42 AM
To: Patrick Schmitz
Cc: 'Chris Martin'; 'Christopher Pott';
talk@lists.collectionspace.org; 'Richard Millet'
Subject: Re: [Talk] adding fields to core schema repeatable groups
Hi Patrick,
My main concern in this kind of thing is always representation:
processes can follow later.
When Chris (M) mentioned this to me, the METAL slot model
came to mind, as used by TAL, which is a kind of glorified
"include" with extra functionality and for an explicit purpose.
http://en.wikipedia.org/wiki/METAL#METAL
We would define in our XML for core parts of the schema named
"slots", eg:
<record id="farm">
<field id="cottage"/>
<group id="flowers">
<field id="id"/>
<field id="name"/>
<field id="colour"/>
<field id="smell"/>
<slot id="flowers-extra"/>
</group>
<slot id="farm-extra"/>
</record>
with no other code, these slots would do nothing.
But if you have, somewhere else in some customisation:
<fill ref="farm-extra">
<field id="dairy"/>
<field id="tractor"/>
</fill>
or
<fill ref="flowers-extra">
<field id="stamen-count"/>
</fill>
Those could be added in. You could even have multiple fills
which would be merged.
The next question which arises is how to link it to the
repeating blocks in the service layer, as you describe. The
fills would, presumably, occur in an XML enclosing
environment defining, or at least defaulting, a schema
section. For example a fill will be defined (somehow) as
being "within" a domain or museum schema through its
structural location just as fields must be (I've forgotten
how we implement this, sorry!).
Given that representation, we can spot cross-section slot
fills and -- with appropriate attributes or defaults on the
fill tags to locate the data within the service schema -- zip
the lists as you describe.
Yes, so I think this is doable in principle and would end up
quite elegant and powerful.
The big question, though, is resources and deadlines. Aiui,
Chris (P) would like this as a part of an SMK deploy so
presumably has reasonably hard deadlines?
Dan.