David et al. I have been following this discussion and trying to determine an appropriate point of entry. So lets dive in...
In @mire, we are highly invested in the DRI solution at this time, proposing a major change in DRI for DSpace 1.7 is not something that @mire will support due to the impact it will have on our clients dspace solutions. Likewise, discussion internally has lead to an opinion that breaking up the xslt into separate files for each page actually defeats the design goals of the XMLUI theming tier. I.E. having one file within which all customizations reside to manage your theme. Using separate files that are overridden introduces a variant to the current approach and possibly more confusion about which template is being applied. The current mechanism relies solely on xslt template priorities for the determination of what templates will be overridden in one theme and we prefer this approach. --- This said, however, I have always been interested in alternatives to METS for flagging the content necessary for rendering a view... The separation of DRI and METS was a bit of an evolutionary attempt to improve the performance and there are some kludges within it. the original design, embedded METS within the DRI, and this it served a "container-ship" role in aggregating all the data that was necessary for the view. Performance required the separation of METS under another pipeline for rendering that content. There are further kludges that introduce a "pseudo XPath" capability to retrieve only specific portions of the METS document"... which is further complexity that end users are unaware of. It was this division of content that made the role DRI less clear. To be honest, the use of generating whole METS docs and handing them to the theme to enable the theme developer to add/remove content from the views is what broke the separation of concerns. It is the "References and ReferencesSets" that point at METS documents that violate the generation of content only in the aspect tier. This became very clear when working on Discovery, I became aware of the use of METS as a source for the search, browse and recently added resultsets in a search is a bit of over engineering and an attempt to model the older JSPUI approaches to selecting the fields from the actual Item object that should be present in search results... Its actually quite a pain to get around. This choice of approach actually makes it more difficult to use the output from the Solr search engine (return fields, hit highlighting, ranking info, etc) to assist in rendering. In which case, I was actually more interested in rendering the search engine results as DRI list elements and not as a set of METS references. I still feel this way, and in which case, for the long term, I'm promoting a solution for discovery that is still DRI centric. So, changing the use of DRI in this area will derail that development direction. So, to be clear, the ability to construct nested divisions, lists, options, meta sections is quite powerful for getting the structure of the content pushed into the presentation layer. We are talking here about not just the semantic structure of the page to be rendered but also the content of the DSpace item, community, collection etc. I see an argument here about "form fields" vs. "links". And this is an example of why we want to use Aspects to generate the content of the page (including the required inputs) as opposed to having the theme developer do it. Adding a form field is a Aspect developer project, deciding if its a plain old textbox or some dynamic html rich text widget is a theming/branding activity. In fact, if one were to make any changes to DRI, it might be argued, based on the above examples, that Most of DRI interactive forms would have been better suited to be Cocoon CFORMS (http://cocoon.apache.org/2.2/blocks/forms/1.0/489_1_1.html). This would have made it very clear that Aspects produce page structural content (including forms) and that Themes simply style that content and give an opportunity to override some the output. This would have reused a key set of tooling already developed in the Cocoon community and in use today in projects such as Apache Lenya. CFORMS are the converse of javascript flow that Tim was talking about, rather than using CFORMS, TAMU instead invented a custom mechanism for representing interactive sections of content in DRI. CFORMS could be employed to replace Interactive DRI sections or at the theming layer to brand the existing DRI as CFORMS. Both are probably viable approaches. Mark On Thu, Oct 7, 2010 at 11:23 AM, Walker, David <dwal...@calstate.edu> wrote: >> We still need some way to build a bag of structured, >> labeled data and action handles, so that when a >> Theme reaches into the bag it can know what to grab > > Yes, right. And this is really easy to do: > > <label>data</label> > > It'll probably need to be more complex than that, of course -- but not much. > >> If we do away with DRI we will have to invent >> something almost like it. > > But what I just described above is nothing like DRI. Unless you count the > fact that they are both XML. > > DRI tries to accomplish a whole bunch of things that a simple attribute-value > pair does not. But, IMO, those things are unnecessary. > > All we *need* is a simple mechanism to get data to the interface. Anything > beyond that just complicates and confuses the process. > > --Dave > > ================== > David Walker > Library Web Services Manager > California State University > http://xerxes.calstate.edu > ________________________________________ > From: Mark H. Wood [mw...@iupui.edu] > Sent: Thursday, October 07, 2010 10:40 AM > To: dspace-tech@lists.sourceforge.net > Subject: Re: [Dspace-tech] manikin question > > Well, one thing which occurs to me is that <dri:field type='button'/> > should instead be something like <dri:action/> and let the Theme > figure out whether it wants to lay out a button (or anything else) > which links to the action. These "button" fields are really just > abstract handles for things the user can ask to have done. If they > weren't *called* buttons, they wouldn't look like presentation. > > If we do away with DRI we will have to invent something almost like > it. We still need some way to build a bag of structured, labeled data > and action handles, so that when a Theme reaches into the bag it can > know what to grab and make good use of XSL facilities to do so. > > What's going on here, it seems to me, is that the current design > strives for separation of concerns between data and presentation > across the Aspect/Theme boundary but perhaps has not quite achieved > it, compounded with the use of terms in DRI which we are conditioned > to think of as presentational. > > -- > Mark H. Wood, Lead System Programmer mw...@iupui.edu > Balance your desire for bells and whistles with the reality that only a > little more than 2 percent of world population has broadband. > -- Ledford and Tyler, _Google Analytics 2.0_ > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > DSpace-tech mailing list > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech > -- Mark R. Diggory Head of U.S. Operations - @mire http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get t...@ther ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
