> 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
