Hi all, Very interesting discussion.
I think there really are two layers of discussion going on here, one is much easier to tackle now, and one is something that may need ongoing discussion/analysis. ------------------------- "Theme" Layer Discussions ------------------------- This is basically the complaint that dri2xhtml/structural.xsl is both: (a) too confusing/complex, and (b) just does a very basic transformation of DRI elements directly into its XHTML counterparts. This is something that could be resolved immediately with no changes to the DRI schema, and likely little-to-no changes to Java Aspects. All we need is someone to volunteer to create a new theme (codename: "QuickStart" theme, or similar). This new "QuickStart" theme needs to *NOT* utilize dri2xhtml/structural.xsl. Instead, it will re-write it's own XSLT into an easier to manage theme, which could include separate templates per page (or XSLTs per page) -- based on what the theme designer(s) decides upon. I believe that building this basic theme would not go against the purposes of Manakin, and it may help in adoption (and also allow users to get up to speed more quickly). Notice, I'm not suggesting to remove or replace DRI2XHTML -- rather, we want an alternative "QuickStart" Theme, that people can build off of instead of DRI2XHTML. Themes which already use DRI2XHTML would be unaffected, and can continue to use that as the basis for their theme, if they choose to. -------------------------------- "DRI" / Aspect Layer Discussions -------------------------------- This is essentially David's (and others) point that perhaps DRI needs some redesign or re-thinking. This obviously is a larger issue, as reworking (or getting rid of) DRI would require major overhaul of all of Manakin. So, I'd deem this a longer term discussion -- still worthwhile to be having, but it needs more analysis. I also think that if we chose to build an "Easy-Start" theme, the creation of that simple theme may help us learn more about what may be limiting to the DRI that is created by aspects, and maybe even what parts of DRI schema could be done away with (maybe it could be vastly simplified). We could also work to apply small fixes to improve specific Aspects which may be "more limiting to Themes" than others. But, any larger scale changes would need more analysis and possibly a team of volunteer working on it. I'm not saying this to discourage discussion of DRI/Aspect changes. Rather, I just want to point out that we may be able to split this into two problems -- one of which we could tackle immediately, if we can find a volunteer or two! Just my quick thoughts, - Tim On 10/12/2010 8:45 AM, Walker, David wrote: >> the Aspect chain accumulates a big pot of potentially useful >> data related to the user's request, and the Theme selects >> and arranges them as required to make them presentable. > >> we need some way to represent logical structure of the data >> before they are selected and laid out. > > I think we fully agree, Mark, that conceptually this is how Manakin *should* > work. And yet, I don't believe this is how Manakin actually does work. > > Themes don't select, arrange, or layout the data on the page. Rather, > dri2xhtml/structural.xsl simply iterates over the DRI XML, converting > individual DRI elements into its individual HTML counterpart. > > The actual order of the data, and thus the essential arrangement and layout > of the page, is controlled by the Aspects, not the Theme. Just a quick > glance at the<body> section of any DRI XML response shows quite plainly that > the structure of the page is set-out here in the XML, not in the XSLT. > > The exception to that rule is the collections/community/item metadata. If > all of Manakin was set-up like those templates are set-up, Manakin would be > much, much easier to use. > > >> That's what I thought DRI was designed to be. If it isn't >> being used that way, I think we should fix *that*. > > To fix the problem -- i.e., to allow Themes to actually select, arrange, and > layout the data on the page -- I see no other course of action but to rewrite > the XSLT. > > To be able to control the layout, you've got to actually allow the XSLT to > lay it out. Create page-based templates wherein someone can put down the > HTML for the page, and thus decide the order and arrangement of the data. > > The thing is, once you do that, you'll quickly see that virtually all of the > DRI can be ignored -- in fact it *has* to be ignored to allow the XSLT to > decide the arrangement of the data. > > At that point, we no longer need an XML schema that defines layers, > paragraphs, headings, unordered lists, and so on -- or, rather, > pseudo-layers, pseudo-paragraphs, pseudo-headings, etc. > > We just need, as you said previously, a way to have structured, labeled data. > We can do that very easily without the overhead, complexity, and ultimately > the confusion that DRI brings with it. > > --Dave > > ================== > David Walker > Library Web Services Manager > California State University > http://xerxes.calstate.edu > ________________________________________ > From: Mark H. Wood [mw...@iupui.edu] > Sent: Monday, October 11, 2010 8:15 AM > To: dspace-tech@lists.sourceforge.net > Subject: Re: [Dspace-tech] manikin question > > On Fri, Oct 08, 2010 at 11:04:51AM -0700, Walker, David wrote: > [quoting Mark Diggory, I believe] >>> 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. >> >> I appreciate your opinion here, Mark. And, yet, I think this illustrates >> precisely why DRI is problematic. >> >> How the content is structured on the page *is* presentation. Conceptually, >> you cannot "push" that to the "presentation layer." Any code (regardless of >> where it lives) that defines the structure of the page *is* the presentation >> layer (or at least part of it). > > Data structure != page structure. We need to keep the namespaces in > mind. A dri:div is not the same kind of thing as an xhtml:div. One > *can* use them in such a way that you eventually transform one into > the other, but then again one might have some completely different use > for a container of unordered data, just as one might use a dri:list to > express something which would never be noticed as an ordered > collection in the XHTML -- it might disappear completely. For that > matter, it might be consumed by a subsequent Aspect and never reach > the Theme engine. Data are structured to make them readily > comprehensible by later stages. A Theme isn't required to treat that > structure as prescriptive of the structure of its output. > > Come to think of it, an Aspect *can't* reliably coerce the final page > structure, at least not in some ways you might want to try. An Aspect > has no way of knowing its position in the chain, or what other Aspects > are included before it, so it can't slot its work into the "right > place on the page"; if it has something to add, it may as well stick > it on the end and assume that some Theme will put it where that Theme > wants it. The DRI document *has to* be an abstract representation of > the content, because only the last stage in the pipeline has the > certainty required to produce a concrete one. > > It took me a while to work out what the parts were doing, > conceptually, but what finally made sense to me was that the Aspect > chain accumulates a big pot of potentially useful data related to the > user's request, and the Theme selects and arranges them as required to > make them presentable. At least, that's the way I've tried to use the > pipeline, and it seems to work. > > Regardless of how the physical structuring of the final page is done, > we need some way to represent logical structure of the data before > they are selected and laid out. That's what I thought DRI was > designed to be. If it isn't being used that way, I think we should > fix *that*. > > -- > 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 ------------------------------------------------------------------------------ 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
