Re: [Dspace-tech] citation field in xmlui

[Walker, David]

 there should be no duplicate numbers

 in the 'test=$clause =' bits.



That was it, thanks, Andrea!



--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Andrea Schweer [schw...@waikato.ac.nz]
Sent: Tuesday, May 17, 2011 7:26 PM
To: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] citation field in xmlui

Hi Dave,

On 18/05/11 11:27, Walker, David wrote:
 I need to add the citation field to the simple item display in Manakin.  I 
 see that the DIM-Handler.xsl already includes the citation field at line 595:

   xsl:when test=$clause = 3 and (dim:field[@element='identifier' and 
 @qualifier='citation'])

 But the field is not displaying.  Is there something obvious I'm missing?

   http://sonoma-dspace.calstate.edu/xmlui/handle/10211.1/684

The record actually has a value for this field, so that's good. Have a
look at the lines in DIM-Handler.xsl below the one you gave -- there
should be no duplicate numbers in the 'test=$clause =' bits.

Hope this helps,

cheers,
Andrea

--
Andrea Schweer
IRR Technical Specialist, ITS Information Systems
The University of Waikato, Hamilton, New Zealand

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] manikin question

[Walker, David]

 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

Re: [Dspace-tech] manikin question

[Walker, David]

This is a very reasonable proposal, Tim.

I feel compelled to put my development time where my mouth is -- and at least 
get something started.  Although we need a cooler name than QuickStart theme. 
;-)

However, DSpace is not my main area of work.  Given my other responsibilities, 
I definitely don't have time to complete a project of this scale by myself.  It 
essentially means re-writing the interface from scratch.

Also, if we are going to rewrite the interface, I think it would be *well* 
worth our time and effort to also redo the Manakin CSS, which IMO needs an 
overhaul as much as the XSLT.

All that being said, I think the *last* thing the DSpace community needs is Yet 
Another Interface.  Obviously, I think Manakin needs to be redesigned.  And, 
equally obviously, a change of that scale would need proceed in parallel to 
existing efforts.

But if the long-term outcome here is just an alternate Theme (albeit one that 
is fundamentally different from all the others), then I think we've just 
created more (and duplicate) work for everyone.  

At some point, it would be good if the developers, or the community as a whole, 
evaluated this alternate approach and actually made a yeah or nay decision 
on it.  Long term, IMO, it either needs to replace the structural.xsl approach 
or just go into the recycle bin.  I don't think it's sustainable otherwise.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Tim Donohue [tdono...@duraspace.org]
Sent: Tuesday, October 12, 2010 7:52 AM
To: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] manikin question

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

Re: [Dspace-tech] manikin question

[Walker, David]

Hey Mark, 

Good to hear your perspective on this. I wanted to respond to some of your 
broader comments here, and then circle back to some specifics ones in a 
separate email.

 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 

Indeed, I can't imagine that the community would support a change of this scale 
for the 1.7 release.  However, I do hope that the community would consider 
rethinking Manakin's design long-term.

I fully appreciate, too, that this change would come at a significant cost, 
both in terms of development resources and disruption to the current install 
base.  

But part of my goal here is to point out that the current Manakin design 
represents a significant cost to the community, too.  

Look no further than this very thread, where Jose is struggling to implement 
what should be a fairly simple change.  And yet Manakin's current design makes 
this task much harder than it needs to be.  

It is costing him (and us, and others who are struggling with the complexity of 
Manakin) a lot in terms of time and resources.  It doesn't need to be this hard.


 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).

So, in Manakin, some presentational logic is set out using DRI in Java Aspects 
code.  And other presentation logic is set out (or overrided) in the XSLT.  
Having presentational logic in two different places is mixing concerns, which 
leads to confusion.

And -- at least in my experience -- Mankin is unique in doing it this way.  

Pretty much every other system we use here -- and almost any other system you 
care to name -- uses some kind of  web templating system for its interface.  
Most don't use XSLT, but, regardless of which templating system they do use, 
the interface is constructed in the *templates*, not back in the programming 
source code.  

 Templatingsystems (including XSLT) are good at this task -- much easier 
than programming code -- which is why they were invented.  I'm simply proposing 
that Manakin should use the XSLT in this way too.

--Dave
==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu


From: mdigg...@gmail.com [mdigg...@gmail.com] On Behalf Of Mark Diggory 
[mdigg...@atmire.com]
Sent: Thursday, October 07, 2010 6:00 PM
To: Walker, David
Cc: Mark H. Wood; dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] manikin question

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
 dspacesolutions.  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
 xslttemplate 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

Re: [Dspace-tech] manikin question

[Walker, David]

 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.

I think there are advantages and disadvantages to both approaches.

But the thrust of my argument here is that we should have *templates* that 
correspond to pages.  Whether each of those templates lives in it own file, or 
whether they all live together in one big file, is a minor detail, as far as 
I'm concerned. 

Regardless of how the files are organized, there shouldn't be much confusion, 
though.  One advantage of having (and calling) *named* templates (e.g., the 
'home page' template) is that you know exactly which one is being used.

 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

To appreciate my argument, Mark, I think you have to divest yourself of how 
Manakin works now, where the XSLT mostly represents the theme layer.   

I'm suggesting that the XSLT should be the presentation layer in total.  

To illustrate that, let's use an example:  Say a developer wants to create some 
new functionality in DSpace where the user will fill in a form, and then DSpace 
sends an email to someone.

In the model I'm suggesting, the developer creates the actual form in HTML in 
an XSLT file.  That's the interface.  He or she then creates the functionality 
of processing the form data and sending out the email in Java Aspects code.

There is no theme developer here, then.  The same person developing the Java 
code is also putting in place the basic form elements in the interface.  It 
kind of has to be that way.

The only difference is *where* that work takes place.  In the current model, 
that takes place in Java source code using DRI.  In my model, that work would 
take place directly in an XSLT template. 

My argument is that it is a lot easier to build an interface with HTML in XSLT 
than it is to write Java source code that constructs DRI (with the possibility 
that you may also have to tweak some XSLT to actually make the interface).

You can still have themes (composed of XSLT and CSS) that override that basic 
interface in this model.

In fact, it would be much easier to create themes in this model, since a theme 
developer (who now comes into play) can much more easily see how pages are laid 
out and where and how to make changes to the page. Which, of course, then makes 
the task of customizing a theme by an institution easier too.

--Dave
==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: mdigg...@gmail.com [mdigg...@gmail.com] On Behalf Of Mark Diggory 
[mdigg...@atmire.com]
Sent: Thursday, October 07, 2010 6:00 PM
To: Walker, David
Cc: Mark H. Wood; dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] manikin question

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
 dspacesolutions.  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
 xslttemplate 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

Re: [Dspace-tech] manikin question

[Walker, David]

Hi Jose,

Text labels are not set in the XSLT, but rather are defined in the 
i18n/messages.xml file.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Blanco, Jose [blan...@umich.edu]
Sent: Thursday, October 07, 2010 7:20 AM
To: Tim Donohue
Cc: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] manikin question

I'm really having a hard time with this.  In order to understand the code a bit 
more, I'm trying to find the line in the themes dir that would put the message 
Find Itme in the url:

http://dspace-test-area/admin/item

So I looked at

http://dspace-test-area/DRI/admin/item

which contains:

document version=1.1
−
body
−
div id=aspect.administrative.item.FindItemForm.div.find-item 
interactive=yes rend=primary administrative item action=/admin/item 
n=find-item method=get
headFind Item/head

So I figure I need to look for some match on the dri:div where 
id=aspect.administrative.item.FindItemForm.div.find-item

But I can't find it.  I have tried removing code to see if I can find it that 
way, but after a whole day of it, I can't find it.  How does 'Find Item' make 
it to the browser window.

Thank you!
Jose

-Original Message-
From: Tim Donohue [mailto:tdono...@duraspace.org]
Sent: Thursday, September 30, 2010 10:26 AM
To: Blanco, Jose
Cc: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] manikin question

Hi Jose,

Actually, that's exactly my point.  There is not a single template that
renders the entire middle of the page.  It's rendered by several
templates working together.

So, if you take a look closely, the middle part of the page is a giant
table (with class=ds-table).  If you dig into the dri2xhtml.xsl file,
you'll see it just loads several other XSLs in the /dri2xhtml/ folder.
In this case, you are looking for templates that generate the structure
of the page -- so, you'd look in /dri2xhtml/structural.xsl  (the
*-Handler.xsl files all deal more with displaying actual metadata values
from the METS files which are generated by Manakin, so you'd look there
if you wanted to customize what metadata values are being displayed on a
particular page).  In the structural.xsl file, there is one main
template that gets called for dri:table contents:

xsl:template match=dri:table

But, notice that template calls several other XSL templates in the file,
by using the xsl:apply-templates or xsl:call-template tag.  So,
depending on what you are looking to change, you may need to follow the
logic between the templates.

Sometimes the easiest way to find a very specific template is to looking
closely at the resulting XHTML that you want to change.  Especially
looking at specific @class attributes on HTML elements.  Oftentimes you
can search for those @class attribute values in the XSL templates to
find where they are being generated.  For example, in this case, you are
looking at a big HTML table with a class=ds-table.  If you search for
ds-table in the structural.xsl, it will jump you right to the template
that generates that content.  (In some cases that @class attribute may
exist in multiple templates, so you'd have to figure out which one you
really need to change.  But, in this example, it's only one place in the
structural.xsl file)

Hope that helps,

- Tim


On 9/30/2010 9:03 AM, Blanco, Jose wrote:
 Tim,

 Thanks for your reply.  I guess what I'm looking for is the xsl within the 
 dri2xhml.xsl file that handles the rendering of the page used when the user 
 confirms he wants to withdraw an item.  I see the code that displays the 
 header and the footer for that page, but I don't see the part that renders 
 the stuff in the middle.

 -Jose
 
 From: Tim Donohue [tdono...@duraspace.org]
 Sent: Wednesday, September 29, 2010 5:37 PM
 To: Blanco, Jose
 Cc: dspace-tech@lists.sourceforge.net
 Subject: Re: [Dspace-tech] manikin question

 Jose,

 I'm not sure I fully understand the question?

 Manakin works much differently than JSPUI -- so there is never really a
 one template to one page relationship.  XSL Templates (in a theme)
 are usually used across many different pages in the system. Also,
 obviously many templates are used to generate a single page.

 The template you are looking for should be either in your Theme's XSL
 file or in the main 'dri2xhml.xsl' file (which is where most of the
 default templates reside -- as this file just basically transforms DRI
 into XHTML).

 If you are having trouble finding the exact template, sometimes it helps
 to look at the DRI structure of that page (add ?XML to the end of the
 Manakin URL, orXML if there's other stuff on the querystring already).

 You also may find it useful to use a tool like FireBug
 (http://getfirebug.com/) to analyze the structure of the generated
 XHTML, so that you can search through the templates in your Theme's XSL
 to find where that structure 

Re: [Dspace-tech] manikin question

[Walker, David]

 Obviously, as we both know, a button won't do anything 
 unless there's some server-side code which understands 
 how to process that request.

Oh, yes, of course.  

Obviously, there needs to be Java code that can processes the incoming request 
and do something about it:  Getting data from the database, for example.  And 
then passing that data back to the interface layer for display.

My point is that the Java code should be *solely* concerned with those tasks.  
It shouldn't try to create the interface.  That's not it's job.  It should be 
concerned with the business logic, not presentational logic.

Now, the presentational layer can't be *completely* disconnected from the 
business logic layer.  That wouldn't make any sense.  And I don't think I ever 
said that.  What I'm saying is that the two need to be *separate* from each 
other.  They are not (or at least not enough) now in Manakin.


 I'm still not 100% sure that DRI could be done
 away with (you haven't swayed me completely yet). 

Let me try some more, then. ;-)

For any presentation layer to create an interface, it needs data.  So, in 
Manakin's case, the Java code needs to create XML that contains enough data for 
the XSLT (which I'm arguing should be the sole presentation layer) to actually 
render a page that the user can see.

Let's take the search results page as an example.  

Not only does the Java code need to actual fetch the search results themselves 
and add that to the XML, but it also needs to tell the interface some things 
about the result set as a whole: 

These are results 1 to 10 of 340, for example.

To achieve that, the Java code could simply put something like this in the XML 
response:

search_results
  total340/total
  start1/start
  end10/end
  ...
/search_results

The XSLT could then create the *presentation* of that data like this:

div class=searchResults
  Results xsl:value-of select=search_results/start to xsl:value-of 
select=search_results/send 
  of xsl:value-of select=search_results/total
/div

(putting aside things like i18n, just for simplicity sake here, of course.)

This is what I mean by *semantically* marked-up XML.  

The XML here isn't trying to tell me anything about how this data should be 
displayed.  It doesn't need to.  Moreover it *shouldn't*.  It just needs to get 
me the *data*, and then the XSLT can create the display, slotting in that data 
in the places it needs to go.

This is how all web templating systems work -- they layout the interface using 
HTML, and then slot-in the data where it needs to go.  

So why do I need DRI?  Why create what is, in effect, a presentational XML 
layer?   As Master Yoda would say: Create HTML or do not, there is no 
intermediary quasi-presentational XML.

Currently, DRI includes some of the data we will need.  But we don't need DRI 
itself.  Just give me the data!

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Tim Donohue [tdono...@duraspace.org]
Sent: Thursday, October 07, 2010 7:59 AM
To: Walker, David
Cc: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] manikin question

Hi Dave,

Meant to get back to this discussion -- but, as you can see, it has
taken me a while to do so :)

On 10/1/2010 4:22 PM, Walker, David wrote:
 If the goal here is to add an input button to the interface -- on the 
 'confirm item' page, let's say -- I think it would be *significantly* easier 
 if the developer could just open an XSLT file, find the 'confirm item' 
 template, and just add the button like this:

input type=submit

 If someone wanted to then change that button to a link or an image, I think 
 it would, again, be significantly easier for them to locate the 'confirm 
 item' template, find that input element, and then change it to:

a href=

 Done.  Easy.

 The way Manakin does it now, by comparison, seems both unnecessarily complex 
 and unnecessarily restrictive.

 To add a button to the interface, the developer has to write several lines of 
 Java code to create a pseudo-button DRI element and add it to the XML 
 response.

 And then if someone wants to change that element, they have to either wade 
 through a bunch of XSL templates to find the right one that can override 
 buttons, or edit the Java source code and then recompile and redeploy Manakin.

 And that's just for this one very simple use case.  If you need to make (even 
 slightly) more complex changes to the interface, like actually *moving* 
 elements around -- putting that button above or below a different interface 
 element, for example -- then you have to edit Java code (cumbersome), or make 
 large-scale changes to the XSLT (a lot of work).

 That just seems ten times more difficult than opening-up an XSLT file, and 
 just editing actual HTML directly.  Am I wrong?


I think you have some good points you've made, and I appreciate it.

However, it is worth

Re: [Dspace-tech] manikin question

[Walker, David]

 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:

  labeldata/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

Re: [Dspace-tech] manikin question

[Walker, David]

 So we really are transforming one XML dialect to another. 

Natch.  

 There may be some tendency to confuse templating in the 
 XSL sense and templating in the web-page sense.  I don't 
 think they are interchangeable. 

Agreed.  I think you can use XSLT for *other* purposes besides as a 
web-templating language.

But you *can* use XSLT as a web templating language.  It's actually pretty good 
for that.  The thrust of my argument here is that Manakin *should* use it in 
that way.

Or, more precisely, it should use it that way *more* than it already does.  

Parts of the Manakin XSLT already follow the approach I'm advocating.  The 
header, the footer, parts of the sidebar, and the community/collection/item 
displays alread follow this web template approach.  

And those are the parts that are easy to understand.  If I want to add or 
remove elements from the full item display, I can do that very easily.  They 
are laid out in a way that makes sense.

But doing something like removing the search box from the home page is no way 
simple or intuitive.  It took us a long time to figure out how to do things 
like that.  It shouldn't be that difficult. 

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Mark H. Wood [mw...@iupui.edu]
Sent: Friday, October 01, 2010 7:45 AM
To: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] manikin question

Picky point: the Theme stage does not produce HTML; it produces XHTML.
So we really are transforming one XML dialect to another.  It's just
that the output dialect has (by design) the nice property that it has
an agreed-upon meaning to web browsers and can be rendered in a
standardized way as pages.

I think we would get a lot more comprehensibility if we just split up
the hge structural.xsl into a collection of modules, concerned
with various bits of the UI, and added a lot of commentary and perhaps
a user's guide.  Having done that, we might more clearly see how to
further refine the collection.  A good sharp look at the code might
indeed suggest that page types could be pulled out.  But I'd like to
plead with the community to design first and *then* execute, rather
than assume that all who have gone before us know more about our task
than we do and simply copy what they have done.

There may be some tendency to confuse templating in the XSL sense and
templating in the web-page sense.  I don't think they are
interchangeable.  Let's see what we get from the current logical
organization and whether it's worth keeping, however we rearrange it
physically.

There's already some modularity:  the metadata Handlers pull out quite
a bit of stuff that one doesn't often need to examine and would not
wish to wade past.

That said, I'll add my voice to those who say that the current code is
difficult to understand and might be made less so.

--
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_
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] manikin question

[Walker, David]

I really appreciate you taking the time to discuss this, Tim.  You make a lot 
of good points.

 For example, a submit button is encoded as 
 dri:field type='button' n='submit' . How and where that  is 
 displayed/presented to the user is up to the XSLT -- it can choose to
 make that an input type=submit, an input type=button, a 
 button, an a href=, any other XHTML element, or even choose 
 to hide it altogether and not display it.

I guess I just have a hard time understanding how this is advantageous.

If the goal here is to add an input button to the interface -- on the 'confirm 
item' page, let's say -- I think it would be *significantly* easier if the 
developer could just open an XSLT file, find the 'confirm item' template, and 
just add the button like this:

  input type=submit

If someone wanted to then change that button to a link or an image, I think it 
would, again, be significantly easier for them to locate the 'confirm item' 
template, find that input element, and then change it to:

  a href=

Done.  Easy.

The way Manakin does it now, by comparison, seems both unnecessarily complex 
and unnecessarily restrictive.  

To add a button to the interface, the developer has to write several lines of 
Java code to create a pseudo-button DRI element and add it to the XML response. 
 

And then if someone wants to change that element, they have to either wade 
through a bunch of XSL templates to find the right one that can override 
buttons, or edit the Java source code and then recompile and redeploy Manakin.

And that's just for this one very simple use case.  If you need to make (even 
slightly) more complex changes to the interface, like actually *moving* 
elements around -- putting that button above or below a different interface 
element, for example -- then you have to edit Java code (cumbersome), or make 
large-scale changes to the XSLT (a lot of work).

That just seems ten times more difficult than opening-up an XSLT file, and just 
editing actual HTML directly.  Am I wrong?

 You can create your theme entirely from 
 scratch if you choose 

Totally.  In fact, right now, I could rewrite the XSLT so that it follows the 
page-based structure that I'm advocating for, and all without having to touch a 
single line of Java code.

Moreover, we could do that while basically ignoring 99% of the current DRI XML 
response -- I know, because we actually started to do this before realizing 
that having our own from-scratch theme would be a maintenance nightmare.

But that just further strengthens my belief that we don't need DRI, or anything 
even like it.   

The XML will need to provide some information for the interface, no doubt.  But 
I see no reason at all to have the kind of quasi-presentational XML elements 
that DRI provides.  

I'm not trying to dump on DRI.  I'm really not.  But, I think, until the 
community can fully appreciate the problem that that approach creates, there is 
a  (totally understandable) reluctance to move away from it.

XSLT can handle *all* of the presentational logic, and makes both building and 
customizing the interface so much easier.  I know, because I've seen it used 
that way in a number of other systems.  

I'm convinced that making the XSLT the (sole) presentation layer is a much 
better approach.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Tim Donohue [tdono...@duraspace.org]
Sent: Friday, October 01, 2010 10:17 AM
To: Walker, David
Cc: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] manikin question

Hi Dave  all,

First off sorry for the semi-long email.

On 9/30/2010 4:56 PM, Walker, David wrote:
 So, wrapping up this long-winded criticism -- you did say this was okay 
 right, Tim? ;-) -- I don't think it would actually take much to improve 
 Manakin.

Yes. Perfectly OK.  I actually got a laugh out of your side comment here :)

 First, just do away with the DRI schema.

 Have the aspects Java code simply create XML that is semantically (rather 
 than presentationally) marked-up.  Just give us the data for communities, 
 collections, items, and the submission process.  Just the data as XML.

I actually feel that DRI mostly *IS* semantic markup (though not to the
same degree as say RDF).  There are places where I agree it does fall
flat and move too much into presentation/layout markup (e.g. tables and
similar).  If you read through the Intro to DRI
(http://www.dspace.org/1_6_2Documentation/ch15.html#N189EE) you'll see
it is actually mostly based on TEI (http://www.tei-c.org/index.xml),
which itself is again mostly semantic in nature. Here's a decent
overview of TEI and the history of it:
http://www.ibm.com/developerworks/library/x-matters30.html

DRI elements were *never* meant to be directly equivalent to XHTML
elements (and maybe the fact that some are named the same is what can be
so confusing).  So, dri:div

Re: [Dspace-tech] manikin question

[Walker, David]

Unfortunately, I think this is a serious weakness of Manakin.

It's realtively easy to change the header, the footer, and the display of 
metadata (collections, communities, items).  But if you need to change anything 
else, you're in for a world of hurt.  

The way dri2xhtml renders the interface is both complex and confusing -- not at 
all the way other interface templating systems (including others that use XSLT) 
are set-up.  

I don't mean to be too critical here -- Manakin is a *big* improvement over 
JSPUI , and it cost me precisely $0, so I'm grateful to the developers, 
regardless.  

But Jose is not the first, nor likely the last, to scratch their head at how 
dri2xhtml is set-up.  It would be great if a future version of Manakin might 
take a different approach.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Tim Donohue [tdono...@duraspace.org]
Sent: Thursday, September 30, 2010 7:25 AM
To: Blanco, Jose
Cc: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] manikin question

Hi Jose,

Actually, that's exactly my point.  There is not a single template that
renders the entire middle of the page.  It's rendered by several
templates working together.

So, if you take a look closely, the middle part of the page is a giant
table (with class=ds-table).  If you dig into the dri2xhtml.xsl file,
you'll see it just loads several other XSLs in the /dri2xhtml/ folder.
In this case, you are looking for templates that generate the structure
of the page -- so, you'd look in /dri2xhtml/structural.xsl  (the
*-Handler.xsl files all deal more with displaying actual metadata values
from the METS files which are generated by Manakin, so you'd look there
if you wanted to customize what metadata values are being displayed on a
particular page).  In the structural.xsl file, there is one main
template that gets called for dri:table contents:

xsl:template match=dri:table

But, notice that template calls several other XSL templates in the file,
by using the xsl:apply-templates or xsl:call-template tag.  So,
depending on what you are looking to change, you may need to follow the
logic between the templates.

Sometimes the easiest way to find a very specific template is to looking
closely at the resulting XHTML that you want to change.  Especially
looking at specific @class attributes on HTML elements.  Oftentimes you
can search for those @class attribute values in the XSL templates to
find where they are being generated.  For example, in this case, you are
looking at a big HTML table with a class=ds-table.  If you search for
ds-table in the structural.xsl, it will jump you right to the template
that generates that content.  (In some cases that @class attribute may
exist in multiple templates, so you'd have to figure out which one you
really need to change.  But, in this example, it's only one place in the
structural.xsl file)

Hope that helps,

- Tim


On 9/30/2010 9:03 AM, Blanco, Jose wrote:
 Tim,

 Thanks for your reply.  I guess what I'm looking for is the xsl within the 
 dri2xhml.xsl file that handles the rendering of the page used when the user 
 confirms he wants to withdraw an item.  I see the code that displays the 
 header and the footer for that page, but I don't see the part that renders 
 the stuff in the middle.

 -Jose
 
 From: Tim Donohue [tdono...@duraspace.org]
 Sent: Wednesday, September 29, 2010 5:37 PM
 To: Blanco, Jose
 Cc: dspace-tech@lists.sourceforge.net
 Subject: Re: [Dspace-tech] manikin question

 Jose,

 I'm not sure I fully understand the question?

 Manakin works much differently than JSPUI -- so there is never really a
 one template to one page relationship.  XSL Templates (in a theme)
 are usually used across many different pages in the system. Also,
 obviously many templates are used to generate a single page.

 The template you are looking for should be either in your Theme's XSL
 file or in the main 'dri2xhml.xsl' file (which is where most of the
 default templates reside -- as this file just basically transforms DRI
 into XHTML).

 If you are having trouble finding the exact template, sometimes it helps
 to look at the DRI structure of that page (add ?XML to the end of the
 Manakin URL, orXML if there's other stuff on the querystring already).

 You also may find it useful to use a tool like FireBug
 (http://getfirebug.com/) to analyze the structure of the generated
 XHTML, so that you can search through the templates in your Theme's XSL
 to find where that structure is generated.

 Hopefully that's helpful.  Let us know if any of this doesn't make sense.

 - Tim

 On 9/29/2010 3:48 PM, Blanco, Jose wrote:
 I'm trying to get a better understanding of Manakin, and I've made a change 
 in the aspect

 ConfirmItemForm.java

 And would like now to experiment with the theme that handles the display of 
 DRIs coming 

Re: [Dspace-tech] manikin question

[Walker, David]

I think Sands hits the problem on the head:

The way virtually every other interface templating system works, each page in 
the system corresponds to an individual template or file.

If I want to make a change to my DSpace home page, I should be able to easily 
find and edit a home page template.  If Jose wants to edit the confirm item 
page, there should be a confirm item template.

Obviously, common elements like the header, footer, sidebar, etc., should be 
pushed into their own templates.  But, otherwise, I should be able to see and 
edit pages.  

That is what I think most people expect to see (I know I did).  In so far as 
Manakin doesn't work that wat, it's confusing.

I'll write some additional thoughts in a second email.

--Dave


==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu


From: Sands Alden Fish [sa...@mit.edu]
Sent: Thursday, September 30, 2010 1:42 PM
To: Tim Donohue
Cc: Walker, David; dspace-tech@lists.sourceforge.net; Blanco, Jose
Subject: Re: [Dspace-tech] manikin question


I think one of the real challenges people run into with Manakin's templating is 
that there is no direct corollary between specific pages and individual 
templates or template files.  Templates apply all over the site to an array of 
pages.   


You can't say oh, i'm in submission, i'll go edit submission.xsl.  Further, 
you can't go looking for the template named submission_page.  On top of that, 
there is also a lot of calling in between templates, passing parameters, etc.  


But I think one of the biggest difficulties is that some of the UI construction 
spans across the Java Cocoon generator code into the templates that depend on 
their output.  


I'll echo David's sentiment that this is a massive improvement over the JSPUI 
and that we owe a lot of thanks to its architects and developers.  It is a 
challenge though, for anyone coming into it for the first time, even with a lot 
of experience in more standard templating architectures, to get to a point 
where the UI design  modification process feels smooth, uninhibited and agile. 
 


The fact that there is an abstract document model in the middle of the 
processing that bears a resemblance to some of the markup it generates does not 
help matters for the uninitiated.  


As far as improvements, I could imagine some refactoring of global XSL 
templates into more feature-specific/page-specific templates, to ease the task 
of locating the point in the code that needs to be changed for a particular UI 
element.  


Early on in my use of Manakin, I started inserting xsl:comment tags at the 
start and end of the XSL templates so that in the generated source, I could 
have a better idea of which piece of code had generated that markup.  This was 
only mildly helpful.  I also tossed around the idea of putting some 
multi-purpose HTML div elements into each page so that there would be an 
anchor that could be used for additional page elements using CSS positioning, 
etc. though that always felt like a messy hack to me.



--
sands fish
Senior Software Engineer
MIT Libraries
Technology Research  Development
sa...@mit.edu
E25-131









On Sep 30, 2010, at 3:28 PM, Tim Donohue wrote:


Hi Dave,

Feedback (whether positive or critical) is always welcome!  Though, 
obviously, it is even more helpful if we can better understand what is 
difficult and perhaps even how it could be improved upon or changed.

Obviously, you mentioned the dri2xhtml being confusing and other systems 
doing things in a clearer way.  I guess it leaves me wondering whether 
you (or anyone else) has suggested improvements which may make it less 
confusing/complex to deal with?  For instance, would it be helpful if 
somehow the structural.xsl is split up (so it's not so large), or is 
it the templates themselves which are not as easy as in other systems?

In general, if there are ways you or anyone else feel Manakin (or any 
part of DSpace for that matter) could be improved, we'd definitely be 
interested to hear them.

Manakin, as an interface framework, really hasn't changed much since 
it's initial release in DSpace 1.5. Obviously, any good 
system/interface/etc should adapt and make improvements over time. So, I 
feel that all the Dspace developers would be interested to hear of 
suggestions for improvements or examples of easier to use interface 
templating systems which we could look at emulating, etc.

Thanks!  Feel free to send thoughts/suggestions to this mailing list. If 
you have specific code/template changes to suggestion you can also enter 
those into our issue tracker at http://jira.dspace.org/

- Tim

On 9/30/2010 1:52 PM, Walker, David wrote:

Unfortunately, I think this is a serious weakness of Manakin.



It's realtively easy to change the header, the footer, and the display of 
metadata (collections, communities, items).  But if you need to change anything 
else, you're in for a world of hurt.



The way

Re: [Dspace-tech] manikin question

[Walker, David]

So, wrapping up this long-winded criticism -- you did say this was okay right, 
Tim? ;-) -- I don't think it would actually take much to improve Manakin.

First, just do away with the DRI schema.  

Have the aspects Java code simply create XML that is semantically (rather than 
presentationally) marked-up.  Just give us the data for communities, 
collections, items, and the submission process.  Just the data as XML.

Second, push all of the presentational logic into the XSLT files. 

Create templates that correspond to pages in the system.  If the interface 
needs a div or a paragraph or a submit button, that should all go into the 
XSLT.  That is where it belongs, in the presentational layer.

You'll then have a clean separation of concerns, easy to figure out templates, 
and happier developers.

Easy for me to say, right? ;-)

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Walker, David
Sent: Thursday, September 30, 2010 2:42 PM
To: Tim Donohue
Cc: Blanco, Jose; dspace-tech@lists.sourceforge.net
Subject: RE: [Dspace-tech] manikin question

The root of the problem, IMO, is that Manakin takes a fundamentally wrong 
approach to XSLT.

The way Manakin works now, it generates XML that is already *presentational* in 
its orientation.  The DRI schema includes elements that are, for all intents 
and purposes, layers, paragraphs, lists, and so on.

The XSLT, then, applies templates recursively to that already very HTML-like 
XML, in order to turn each element into true HTML.

This creates two fundamental issues:

(1) People don't design pages recursively.

Applying templates recursively to XML is great (and considered best practice) 
if you are going from one XML document to another XML document -- by that I 
mean, from one metadata schema to another, like from MODS to Dublin Core.

But when you go from XML to HTML for *presentation* (which is what Manakin is 
doing), it's not the right approach.  At all.

As I mentioned earlier, the templates should more-or-less correspond to pages, 
so developers can see, position, and layout the HTML.  That is how other 
systems that use XSLT for presentation work.

(2) It mixes concerns.

The aspects Java code (e.g., CollectionViewer.java) includes code for things 
like querying the database.  But it also includes code for things like 
positioning layers, paragraphs, and buttons in the interface.  You've got 
business logic and presentational logic in one file.

But then you've also got *additional* presentational logic in the XSLT.  So 
you've got presentational logic in two different places in the system.  It just 
adds to the confusion.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Tim Donohue [tdono...@duraspace.org]
Sent: Thursday, September 30, 2010 12:28 PM
To: Walker, David
Cc: Blanco, Jose; dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] manikin question

Hi Dave,

Feedback (whether positive or critical) is always welcome!  Though,
obviously, it is even more helpful if we can better understand what is
difficult and perhaps even how it could be improved upon or changed.

Obviously, you mentioned the dri2xhtml being confusing and other systems
doing things in a clearer way.  I guess it leaves me wondering whether
you (or anyone else) has suggested improvements which may make it less
confusing/complex to deal with?  For instance, would it be helpful if
somehow the structural.xsl is split up (so it's not so large), or is
it the templates themselves which are not as easy as in other systems?

In general, if there are ways you or anyone else feel Manakin (or any
part of DSpace for that matter) could be improved, we'd definitely be
interested to hear them.

Manakin, as an interface framework, really hasn't changed much since
it's initial release in DSpace 1.5. Obviously, any good
system/interface/etc should adapt and make improvements over time. So, I
feel that all the Dspace developers would be interested to hear of
suggestions for improvements or examples of easier to use interface
 templatingsystems which we could look at emulating, etc.

Thanks!  Feel free to send thoughts/suggestions to this mailing list. If
you have specific code/template changes to suggestion you can also enter
those into our issue tracker at http://jira.dspace.org/

- Tim

On 9/30/2010 1:52 PM, Walker, David wrote:
 Unfortunately, I think this is a serious weakness of Manakin.

 It's realtively easy to change the header, the footer, and the display of 
 metadata (collections, communities, items).  But if you need to change 
 anything else, you're in for a world of hurt.

 The way dri2xhtml renders the interface is both complex and confusing -- not 
 at all the way other interface templating systems (including others that use 
 XSLT) are set

Re: [Dspace-tech] manikin question

[Walker, David]

The root of the problem, IMO, is that Manakin takes a fundamentally wrong 
approach to XSLT.

The way Manakin works now, it generates XML that is already *presentational* in 
its orientation.  The DRI schema includes elements that are, for all intents 
and purposes, layers, paragraphs, lists, and so on.  

The XSLT, then, applies templates recursively to that already very HTML-like 
XML, in order to turn each element into true HTML.

This creates two fundamental issues:

(1) People don't design pages recursively. 

Applying templates recursively to XML is great (and considered best practice) 
if you are going from one XML document to another XML document -- by that I 
mean, from one metadata schema to another, like from MODS to Dublin Core.  

But when you go from XML to HTML for *presentation* (which is what Manakin is 
doing), it's not the right approach.  At all.

As I mentioned earlier, the templates should more-or-less correspond to pages, 
so developers can see, position, and layout the HTML.  That is how other 
systems that use XSLT for presentation work.

(2) It mixes concerns.  

The aspects Java code (e.g., CollectionViewer.java) includes code for things 
like querying the database.  But it also includes code for things like 
positioning layers, paragraphs, and buttons in the interface.  You've got 
business logic and presentational logic in one file. 

But then you've also got *additional* presentational logic in the XSLT.  So 
you've got presentational logic in two different places in the system.  It just 
adds to the confusion.

--Dave 

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Tim Donohue [tdono...@duraspace.org]
Sent: Thursday, September 30, 2010 12:28 PM
To: Walker, David
Cc: Blanco, Jose; dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] manikin question

Hi Dave,

Feedback (whether positive or critical) is always welcome!  Though,
obviously, it is even more helpful if we can better understand what is
difficult and perhaps even how it could be improved upon or changed.

Obviously, you mentioned the dri2xhtml being confusing and other systems
doing things in a clearer way.  I guess it leaves me wondering whether
you (or anyone else) has suggested improvements which may make it less
confusing/complex to deal with?  For instance, would it be helpful if
somehow the structural.xsl is split up (so it's not so large), or is
it the templates themselves which are not as easy as in other systems?

In general, if there are ways you or anyone else feel Manakin (or any
part of DSpace for that matter) could be improved, we'd definitely be
interested to hear them.

Manakin, as an interface framework, really hasn't changed much since
it's initial release in DSpace 1.5. Obviously, any good
system/interface/etc should adapt and make improvements over time. So, I
feel that all the Dspace developers would be interested to hear of
suggestions for improvements or examples of easier to use interface
 templatingsystems which we could look at emulating, etc.

Thanks!  Feel free to send thoughts/suggestions to this mailing list. If
you have specific code/template changes to suggestion you can also enter
those into our issue tracker at http://jira.dspace.org/

- Tim

On 9/30/2010 1:52 PM, Walker, David wrote:
 Unfortunately, I think this is a serious weakness of Manakin.

 It's realtively easy to change the header, the footer, and the display of 
 metadata (collections, communities, items).  But if you need to change 
 anything else, you're in for a world of hurt.

 The way dri2xhtml renders the interface is both complex and confusing -- not 
 at all the way other interface templating systems (including others that use 
 XSLT) are set-up.

 I don't mean to be too critical here -- Manakin is a *big* improvement over 
 JSPUI , and it cost me precisely $0, so I'm grateful to the developers, 
 regardless.

 But Jose is not the first, nor likely the last, to scratch their head at how 
 dri2xhtml is set-up.  It would be great if a future version of Manakin might 
 take a different approach.

 --Dave

 ==
 David Walker
 Library Web Services Manager
 California State University
 http://xerxes.calstate.edu
 
 From: Tim Donohue [tdono...@duraspace.org]
 Sent: Thursday, September 30, 2010 7:25 AM
 To: Blanco, Jose
 Cc: dspace-tech@lists.sourceforge.net
 Subject: Re: [Dspace-tech] manikin question

 Hi Jose,

 Actually, that's exactly my point.  There is not a single template that
 renders the entire middle of the page.  It's rendered by several
 templates working together.

 So, if you take a look closely, the middle part of the page is a giant
 table (with class=ds-table).  If you dig into the dri2xhtml.xsl file,
 you'll see it just loads several other XSLs in the /dri2xhtml/ folder.
 In this case, you are looking for templates

[Dspace-tech] No resumption token?

[Walker, David]

Hi all,

I'm trying to harvest our DSpace repos using the PKP OAI Harvester.

The problem I face right now is that the Harvester is only pulling back just 
the first batch of records, instead of all records in the repo.  I see this 
with all of our repos with more than 100 records.

Just looking at the ListRecord response myself, I don't see a resumption token, 
which would explain the behavior of the harvester stopping with this first 
batch:

   
http://sjsu-dspace.calstate.edu/oai/request?verb=ListRecordsmetadataPrefix=oai_dc

George Kozak at Cornell reported a similar problem back in October, but not 
sure if he or someone else was able to resolve the problem:

  http://old.nabble.com/OAI-Harvesting-problem-to25872830.html#a25887911

I'm new to harvesting, so I may have missed something obvious.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] XMLUI: checkbox labels?

[Walker, David]

I see 'remove' in the XML itself, in a DRI label node.  So it's not going to 
be in either the XSLT or messages.xml.  Must be hard-coded in the Java 
somewhere -- I draw the line at searching through Java code. ;-)

I wonder, though, if you might be able to just nix it with CSS?  I would 
suspect, too, that the label is important for accessibility, so that might the 
better route altogether.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Dorothea Salo [dorothea.s...@gmail.com]
Sent: Tuesday, January 05, 2010 7:13 AM
To: Jason Fowler
Cc: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] XMLUI: checkbox labels?

I thought so at first! But no, I don't see the actual text remove or
selected or anything of the sort anywhere nearby.

(For context, I'm trying to get rid of those two labels specifically
because they gunk up the display for no real usability benefit.)

Dorothea

On Tue, Jan 5, 2010 at 9:07 AM, Jason Fowler jfow...@sbts.edu wrote:
 Dorothea,

 Could it be in the lines in structural.xsl that look like this?

 input type=checkbox value={concat(@n,'_',$position)} 
 name={concat(@n,'_selected')}/

 Jason Fowler, CA, MSLS
 Archives and Special Collections Librarian
 The Southern Baptist Theological Seminary
 Vice President, ALABI
 jfow...@sbts.edu
 
 From: Dorothea Salo [dorothea.s...@gmail.com]
 Sent: Tuesday, January 05, 2010 9:38 AM
 To: Dspace Tech
 Subject: [Dspace-tech] XMLUI: checkbox labels?

 Does anybody know offhand where the labels on checkboxes (e.g.
 remove and selected in English) are actually set? I've trawled
 through messages.xml, structural.xsl, and a bunch of Java and I just
 can't find them.

 I'm sure I'll feel stupid when I'm told where to look...

 Dorothea

 --
 Dorothea Salods...@library.wisc.edu
 Digital Repository Librarian  AIM: mindsatuw
 University of Wisconsin
 Rm 218, Memorial Library
 (608) 262-5493

 --
 This SF.Net email is sponsored by the Verizon Developer Community
 Take advantage of Verizon's best-in-class app development support
 A streamlined, 14 day to market process makes app distribution fast and easy
 Join now and get one step closer to millions of Verizon customers
 http://p.sf.net/sfu/verizon-dev2dev
 ___
 DSpace-tech mailing list
 DSpace-tech@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dspace-tech




--
Dorothea Salods...@library.wisc.edu
Digital Repository Librarian  AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] XMLUI: checkbox labels?

[Walker, David]

As I start my second cup of coffee, Dorthea, I realize you might add something 
like this to your theme XSLT as well:

xsl:template match=dri:label priority=1 mode=nested
xsl:if test=text() != 'remove' and text() != 'selected'
  xsl:copy-of select=./node()/
/xsl:if
/xsl:template

Or in some way override that template to achieve your goal.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Walker, David
Sent: Tuesday, January 05, 2010 7:33 AM
To: Dorothea Salo; Jason Fowler
Cc: dspace-tech@lists.sourceforge.net
Subject: RE: [Dspace-tech] XMLUI: checkbox labels?

I see 'remove' in the XML itself, in a DRI label node.  So it's not going to 
be in either the XSLT or messages.xml.  Must be hard-coded in the Java 
somewhere -- I draw the line at searching through Java code. ;-)

I wonder, though, if you might be able to just nix it with CSS?  I would 
suspect, too, that the label is important for accessibility, so that might the 
better route altogether.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Dorothea Salo [dorothea.s...@gmail.com]
Sent: Tuesday, January 05, 2010 7:13 AM
To: Jason Fowler
Cc: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] XMLUI: checkbox labels?

I thought so at first! But no, I don't see the actual text remove or
selected or anything of the sort anywhere nearby.

(For context, I'm trying to get rid of those two labels specifically
because they gunk up the display for no real usability benefit.)

Dorothea

On Tue, Jan 5, 2010 at 9:07 AM, Jason Fowler jfow...@sbts.edu wrote:
 Dorothea,

 Could it be in the lines in structural.xsl that look like this?

 input type=checkbox value={concat(@n,'_',$position)} 
 name={concat(@n,'_selected')}/

 Jason Fowler, CA, MSLS
 Archives and Special Collections Librarian
 The Southern Baptist Theological Seminary
 Vice President, ALABI
 jfow...@sbts.edu
 
 From: Dorothea Salo [dorothea.s...@gmail.com]
 Sent: Tuesday, January 05, 2010 9:38 AM
 To: Dspace Tech
 Subject: [Dspace-tech] XMLUI: checkbox labels?

 Does anybody know offhand where the labels on checkboxes (e.g.
 remove and selected in English) are actually set? I've trawled
 through messages.xml, structural.xsl, and a bunch of Java and I just
 can't find them.

 I'm sure I'll feel stupid when I'm told where to look...

 Dorothea

 --
 Dorothea Salods...@library.wisc.edu
 Digital Repository Librarian  AIM: mindsatuw
 University of Wisconsin
 Rm 218, Memorial Library
 (608) 262-5493

 --
 This SF.Net email is sponsored by the Verizon Developer Community
 Take advantage of Verizon's best-in-class app development support
 A streamlined, 14 day to market process makes app distribution fast and easy
 Join now and get one step closer to millions of Verizon customers
 http://p.sf.net/sfu/verizon-dev2dev
 ___
 DSpace-tech mailing list
 DSpace-tech@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dspace-tech




--
Dorothea Salods...@library.wisc.edu
Digital Repository Librarian  AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] How do I override a message key in a theme?

[Walker, David]

Hi Richard,

Try this.  In your theme XSLT add:

xsl:template match=i18n:text
  xsl:choose
   xsl:when test=text() = 'xmlui.ArtifactBrowser.AdvancedSearch.type_title'
xsl:textRecipient/xsl:text
   /xsl:when
   xsl:otherwise
xsl:copy-of select=./
   /xsl:otherwise
  /xsl:choose
/xsl:template

This is untested, but I think this (or something like it) should work.

--Dave


==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu


From: Jizba, Richard [richardji...@creighton.edu]
Sent: Wednesday, October 07, 2009 9:37 AM
To: dspace-tech@lists.sourceforge.net
Subject: [Dspace-tech] How do I override a message key in a theme?


Hello,
Within a theme, is there a way to override a message key from messages.xml
For example, what if I want to change this:
  message key=xmlui.ArtifactBrowser.AdvancedSearch.type_titleTitle/message
To this:
   message 
key=xmlui.ArtifactBrowser.AdvancedSearch.type_titleRecipient/message
Richard
Creighton University
I originally asked this question as:
Can someone tell me how to change the text/labels on the Advanced
Search - Search Type options for a particular collection or community?
This community does have its own theme. I want to change the text, not
the search itself. 
Example:
I want to keep a title search but change the label to Recipient
because in this community are collections of personal letters and the
Recipient is the logical equivalent of the title in other collections.
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Modifying Manakin's Administrative Section

[Walker, David]

Try this, Sean:

xsl:template match=dri:options/dri:list[dri:list] priority=4
 xsl:apply-templates select=dri:head/
 div
  xsl:call-template name=standardAttributes
   xsl:with-param name=classds-option-set/xsl:with-param
  /xsl:call-template
  ul class=ds-options-list
   xsl:apply-templates select=*[not(name()='head')] mode=nested/
   xsl:if test=@n='administrative'
lia href=#ask a librarian/a/li
   /xsl:if
  /ul
 /div
/xsl:template

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Sean Carte [sean.ca...@gmail.com]
Sent: Tuesday, September 15, 2009 1:49 AM
To: dspace-tech
Subject: Re: [Dspace-tech] Modifying Manakin's Administrative Section

2009/8/15 Sean Carte sean.ca...@gmail.com:
 2009/8/14 Williams, Steven D s.willi...@austin.utexas.edu:

 You can use XSL do modify the DRI document. Add ?XML to the URL in your 
 browser so see what is available in the DRI document. You can then create a 
 XSL template that navigates the DRI document and overlays your with your 
 content. The XSL template would go in your theme XSL file.

Unfortunately I'm still stuck. And this is despite receiving some
expert advice outside of the list, which included a crash-course in
XML/XSLT.

Sorry for trying everybody's patience, but I'd really like to get this right.

I've got as far as being able to add my link after the Administrative
block (bottom right in the Reference theme). But what I want to do is
add a link to that block. Is this doable?

This is the code I've added to my theme XSL file:

xsl:template match=dri:options/dri:li...@n='administrative']
xsl:apply-templates /
a href=#ask a librarian/a
/xsl:template

That's not quite what I want as it displays whether an admin user is
logged in or not, and has the added problem of mucking up the layout
of the Administrative group when logged in.

Any (polite) suggestions?

Sean
--
Sean Carte
esAL Library Systems Manager
+27 72 898 8775
+27 31 373 2490
fax: 0866741254
http://esal.dut.ac.za/

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] DSpace Creative Commons license display problem

[Walker, David]

Mark Diggory mentioned previously that he figured out how to change the 
mime-type.  He didn't mention how, exactly -- perhaps a more detailed 
explanation would help folks work around this issue?

  http://www.mail-archive.com/dspace-tech@lists.sourceforge.net/msg05740.html

Further down that page is the hack that we -- sadly -- still continue to 
implement here. 

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Jason Fowler [jfow...@sbts.edu]
Sent: Tuesday, August 11, 2009 1:27 PM
To: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] DSpace Creative Commons license display problem

I wouldn't even mind if someone knew some good script-fu to actually change the 
bitstream format of license_text to HTML at regular intervals. I would rather 
have it stored correctly and work correctly, but if I need to choose between 
the two, I would rather it work correctly.

Thanks,
jf

-Original Message-
From: Federico Lazcano [mailto:federico.lazc...@gmail.com]
Sent: Tuesday, August 11, 2009 4:17 PM
To: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] DSpace Creative Commons license display problem

El Tuesday 11 August 2009 13:44:22 Jason Fowler escribió:
 We're running DSpace 1.5.1. Last year there was an issue where DSpace
 creative commons licenses would not appear correctly in XMLUI when viewing
 in Firefox.

 I was just wondering if a fix for this was ever developed for this.

 Thanks,
 Jason


 [cid:image001.png@01CA1A81.73C4A150]

I'm interested too.

--

Federico Lazcano

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Cannot understand tooltip text for title using manakin interface

[Walker, David]

This is a COINS.  See:

  http://ocoins.info/

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: John Preston [byhisde...@gmail.com]
Sent: Wednesday, June 10, 2009 8:14 AM
To: dspace-tech@lists.sourceforge.net
Subject: [Dspace-tech] Cannot understand tooltip text for title using manakin 
interface

Can anyone say what is used to construct  the tooltip text for the title of an 
item displayed using the manakin interface. The attached image shows what I see 
when I hold the cursor over the title of an item in the summary view page. 
Needless to say I can't make head or tail of it.

John

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Hide My Account in Manakin

[Walker, David]

Hey Damian,

You probably want something like this in your theme XSLT (un-tested, sorry):

xsl:template match=dri:options/dri:li...@n = 'account'] priority=5
 
 xsl:if test= [ page logic here ] 
  xsl:apply-templates select=dri:head /
 
  div
   xsl:call-template name=standardAttributes
xsl:with-param name=classds-option-set/xsl:with-param
   /xsl:call-template
 
   ul class=ds-simple-list
xsl:apply-templates select=dri:item mode=nested/
   /ul
  /div
 xsl:if
/xsl:template

If you wanted to remove the My Account box completely, you could just have this 
template do nothing.  

But to have it appear on *certain* pages, you're going to have to replace the 
'[ page logic here ]' above with some kind of XPath expression that would look 
at, for example, the request URI data in the meta section of the Manakin XML, 
or perhaps the 'n' attribute on the first div in the body section.  Based 
on the values there, you could control which pages would continue to render 
this option.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu


From: Damian Marinaccio [dxm...@rit.edu]
Sent: Thursday, May 14, 2009 9:25 AM
To: dspace-tech@lists.sourceforge.net
Subject: [Dspace-tech] Hide My Account in Manakin


How would I hide the “My Account” log in box (along with the links).

I have tried a number of things. I know this portion of the page doesn’t  
actually doesn’t get built in structural.xsl I can’t seem to get it to work.

I don’t want to disable the controlling aspect, just hide it on some pages.

Any help would be appreciated.

Thanks.
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] [Dspace-general] digital image collections

[Walker, David]

These are great, Kim!  

I'd like to add some snippets as well.  However, Michele mentioned in a 
previous email that We would like to use JIRA(jira.dspace.org) as a central 
spot to describe and host manakin themes.

I personally would rather use the wiki.  But if others want to use JIRA that's 
cool.  Seem like we should agree on one spot, though.  So . . . which should we 
use?

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: dspace-general-boun...@mit.edu [dspace-general-boun...@mit.edu] On Behalf 
Of Kim Shepherd [k...@waikato.ac.nz]
Sent: Thursday, April 02, 2009 1:42 PM
To: Dorothea Salo; dspace
Cc: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-general] digital image collections

I've created a Wiki page for snippets/recipes, hopefully themes can be linked 
to from there as well:

http://wiki.dspace.org/index.php/Manakin_Themes_and_Recipes

My initial layout might need tweaking, but I thought I'd have a go at getting 
the ball rolling on this while I had a snippet to share.

I have a few more recipes to put up, but will wait until I know I'm on the 
right track with this wiki page..

Cheers,

Kim

 -Original Message-
 From: dspace-general-boun...@mit.edu [mailto:dspace-general-
 boun...@mit.edu] On Behalf Of Dorothea Salo
 Sent: Friday, 3 April 2009 1:58 a.m.
 To: dspace
 Subject: Re: [Dspace-general] digital image collections

 2009/4/2 Joachim Räth j.ra...@stadtteilgeschichten.net:
  Here is another example from Germany, mixing library records and
 historic
  images:
  http://stadtteilgeschichten.net/browse-date
  We are actually in the process of designing a new - less technical -
 layout
  using Manakin, but are still in need of some help.
  A central source for open DSpace Manakin themes would therefor be
 greatly
  appreciated.

 I agree, and have for some time... but to get forward motion on this,
 best to bring it forward on the dspace-tech list. If we could get a
 small flash mob together asking for this, it might actually happen. :)
 Just me asking for it (as I have, several times) is unlikely to
 accomplish anything, as I am a notorious annoyance.

 Dorothea

 --
 Dorothea Salods...@library.wisc.edu
 Digital Repository Librarian  AIM: mindsatuw
 University of Wisconsin
 Rm 218, Memorial Library
 (608) 262-5493

 ___
 Dspace-general mailing list
 dspace-gene...@mit.edu
 http://mailman.mit.edu/mailman/listinfo/dspace-general

___
Dspace-general mailing list
dspace-gene...@mit.edu
http://mailman.mit.edu/mailman/listinfo/dspace-general
--
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

[Dspace-tech] Dublin Core in simple archive format import

[Walker, David]

Just a quick question about importing using the simple archive format: 

Is Dspace expecting that the dublin_core.xml file will have a dublin core 
namespace declaration?  Or does it just look for tags with dcvalue / 
regardless of namespace?

--Dave



==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
--
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Dublin Core in simple archive format import

[Walker, David]

Thanks, Dorthea!

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Dorothea Salo [ds...@library.wisc.edu]
Sent: Tuesday, March 10, 2009 10:08 AM
To: Dspace Tech
Subject: Re: [Dspace-tech] Dublin Core in simple archive format import

On Tue, Mar 10, 2009 at 12:01 PM, Walker, David dwal...@calstate.edu wrote:
 Just a quick question about importing using the simple archive format:

 Is Dspace expecting that the dublin_core.xml file will have a dublin core 
 namespace declaration?  Or does it just look for tags with dcvalue / 
 regardless of namespace?

Can't say for sure, but I half suspect DSpace would choke if
namespaces entered into the matter at all... in any case, no, it
doesn't expect one.

Dorothea

--
Dorothea Salods...@library.wisc.edu
Digital Repository Librarian  AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493

--
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
--
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Dublin Core in simple archive format import

[Walker, David]

Cool, thanks for the additional info, Mark.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Diggory Mark [mdigg...@gmail.com]
Sent: Tuesday, March 10, 2009 11:13 AM
To: Walker, David
Cc: Dspace Tech
Subject: Re: [Dspace-tech] Dublin Core in simple archive format import

Dave,

Yes, there is no standardization in the xml format of that file, its
xml structure actually has nothing to do with the dublin core namespace.

 dublin_core
 dcvalue element=contributorKristine Turner/dcvalue
 dcvalue element=date
 qualifier=accessioned2005-01-10T02:46:14Z/dcvalue
 dcvalue element=date
 qualifier=available2005-01-10T02:46:14Z/dcvalue
 dcvalue element=date qualifier=issued2005-01-10T02:46:14Z/
 dcvalue
 dcvalue element=format qualifier=mimetypeapplication/
 msword/dcvalue
 dcvalue element=format qualifier=mimetypeapplication/pdf/
 dcvalue
 dcvalue element=language qualifier=isoen/dcvalue
 dcvalue element=title qualifier=noneInformation Seeking,
 Retrieving, Reading, and Storing Behaviour of Library Users/dcvalue
 /dublin_core

What I was referring to earlier was the usage of the schema attribute
like this... if you add your own metadata schemas to the metadata
registry, then you can designate those here as well


 dublin_core
 dcvalue schema=dc element=contributorKristine Turner/
 dcvalue
 dcvalue schema=dc element=language qualifier=isoen/
 dcvalue
 dcvalue schema=dc element=title
 qualifier=noneInformation Seeking, Retrieving, Reading, and
 Storing Behaviour of Library Users/dcvalue

   dcvalue schema=myprefix element=myelement
 qualifier=myqualifierMy Value/dcvalue

 /dublin_core


Mark

On Mar 10, 2009, at 10:40 AM, Walker, David wrote:

 Thanks, Dorthea!

 --Dave

 ==
 David Walker
 Library Web Services Manager
 California State University
 http://xerxes.calstate.edu
 
 From: Dorothea Salo [ds...@library.wisc.edu]
 Sent: Tuesday, March 10, 2009 10:08 AM
 To: Dspace Tech
 Subject: Re: [Dspace-tech] Dublin Core in simple archive format import

 On Tue, Mar 10, 2009 at 12:01 PM, Walker, David
 dwal...@calstate.edu wrote:
 Just a quick question about importing using the simple archive
 format:

 Is Dspace expecting that the dublin_core.xml file will have a
 dublin core namespace declaration?  Or does it just look for tags
 with dcvalue / regardless of namespace?

 Can't say for sure, but I half suspect DSpace would choke if
 namespaces entered into the matter at all... in any case, no, it
 doesn't expect one.

 Dorothea

 --
 Dorothea Salods...@library.wisc.edu
 Digital Repository Librarian  AIM: mindsatuw
 University of Wisconsin
 Rm 218, Memorial Library
 (608) 262-5493

 --
 ___
 DSpace-tech mailing list
 DSpace-tech@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dspace-tech
 --
 ___
 DSpace-tech mailing list
 DSpace-tech@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dspace-tech

~
Mark R. Diggory
http://purl.org/net/mdiggory/homepage
--
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Dspace 1.5.1 - Manakin XSLT / DRI

[Walker, David]

 Is there something I can do to have it show a 
 more complete set of data? 

Try this instead.  Not sure if it will yield _more_ data, but it is, I think, 
the DRI XML prior to the i18n transform:

   http://{hostname}.{server}.{extension}/{dspace-instance}/?XML


 How would one tap into / modify the existing DRI? Or might 
 this just be a bad idea even for small changes such as the 
 posted example?

In my opinion (others will disagree, I think), interface changes should 
_always_ be done in the XSLT.  You're going to be making changes there anyway, 
and it's best to keep all of your custom presentational logic in one place.

I think one of the challenges we face in Manakin is that the DRI schema itself 
contains elements that are, for all intents and purposes, presentational in 
their meaning.  So some presentational logic is actually inherent in the XML, 
which cannot then be easily overridden in the XSLT.

But, even though in some cases it would actually appear more straight forward 
to alter the DRI XML to arrive at your desired interface, I think that will 
cause you more problems down the road when it comes time to upgrade DSpace.  
XSLT changes give you a better buffer in that regard.

--Dave
==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu


From: Patrick K. Etienne [patrick.etie...@library.gatech.edu]
Sent: Friday, February 27, 2009 10:00 AM
To: dspace-tech@lists.sourceforge.net
Subject: [Dspace-tech] Dspace 1.5.1 - Manakin XSLT / DRI


DSpace Techies -


I'm looking for some assistance with understanding (primarily) Manakin's DRI.
Here's a simple example task:


Changing the base URI for css stylesheets.
Current location is: {theme-name}/lib/{stylesheet-name}.css
Desired location is: {theme-name}/css/{stylesheet-name}.css


The template to overwrite is: buildHead


Here's the relevant portion of the XSLT:
xsl:attribute name=href
xsl:value-of 
select=/dri:document/dri:meta/dri:pageMeta/dri:metada...@element='contextPath'][not(@qualifier)]/
xsl:text/themes//xsl:text
xsl:value-of 
select=/dri:document/dri:meta/dri:pageMeta/dri:metada...@element='theme']...@qualifier='path']/
xsl:text//xsl:text
xsl:value-of select=./
/xsl:attribute


Now this *could* be done by something as simple as removing the nested tags 
from the xsl:attribute/ tag, but I'd prefer to do in a manner that would seem 
more proper - tapping into the DRI and perhaps even modifying it's content 
slightly.


The Problem:
Directing my browser to 
http://{hostname}.{server}.{extension}/{dspace-instance}/DRI/; does yield the 
raw xml for the DRI, but the document - meta - pageMeta - theme element 
doesn't seem to exist. At least in the browser's output:


pageMeta
metadata element=contextPath/
metadata element=request qualifier=queryString/
metadata element=request qualifier=schemehttp/metadata
metadata element=request qualifier=serverPort8080/metadata
metadata element=request 
qualifier=serverNamedld.library.gatech.edu/metadata
metadata element=request qualifier=URI/
metadata element=search qualifier=simpleURL/search/metadata
metadata element=search qualifier=advancedURL/advanced-search/metadata
metadata element=search qualifier=queryFieldquery/metadata
metadata element=page qualifier=contactURL/contact/metadata
metadata element=page qualifier=feedbackURL/feedback/metadata 
metadata element=titleDSpace Home/metadata
metadata element=feed qualifier=rss+xml/feed/rss_1.0/site/metadata
metadata element=feed qualifier=rss+xml/feed/rss_2.0/site/metadata
trail target=DSpace Home/trail
/pageMeta


Questions:
1) Why does the DRI in my browser seem to be incomplete? Is there something I 
can do to have it show a more complete set of data? Or is this just a 
limitation imposed by when the content gets generated from the pipelines?
2) How would one tap into / modify the existing DRI? Or might this just be a 
bad idea even for small changes such as the posted example?
3) What suggestions might you offer as a best solution for accomplishing tasks 
that involve the XSLT and DRI for presentation level changes?


Any tips, hints, or suggestions would definitely be appreciated
Many Thanks!


 - Patrick Etienne


---
Patrick K. Étienne
Systems Analyst
Digital Library Development
Library and Information Center
Georgia Institute of Technology
email: patrick.etie...@library.gatech.edu
phone: 404.385.8121
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Federating a number of DSpace instances

[Walker, David]

We have that use case here, John -- we are implementing separate DSpace 
instances for our 23 campuses, but we also need a separate interface that can 
search them all.

We're just going to harvest the data using OAI-PMH.  I'm sure you've thought of 
that, too.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: John Preston [byhisde...@gmail.com]
Sent: Tuesday, February 10, 2009 8:53 AM
To: dspace-tech@lists.sourceforge.net
Subject: [Dspace-tech] Federating a number of DSpace instances

Does anyone know if any work is going on regarding federating a number
of DSpace instances so that the group could be considered as a single
DSpace instance for searching say. My use case has a number of DSpace
instances that are operated and maintained as individual instances.
When a user wishes to search for some information, then the search is
performed across all instances, and returns links to where the info
was found on the individual instance.

John

--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Custom Javascript in Structural.xsl

[Walker, David]

You could just write the Javascript in a seperate .js file and import it into 
the HTML using a script tag.  That would free you from the constraints of 
XSLT, and makes things cleaner anway.

--Dave
==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: mikan.d.dspace listmail [mikan.dsp...@gmail.com]
Sent: Wednesday, February 04, 2009 6:46 AM
To: Andreas Geyrecker
Cc: dspace-t...@lists.sourceforge.net.
Subject: Re: [Dspace-tech] Custom Javascript in Structural.xsl

Thanks Adnreas,

This seems to fix the problem with '' signs etc. But now Im getting
the following Javascript errors.
This is strange since the same piece of code works fine in dummy HTML
page. Something seems to go wrong when adding JS to XSL. What am I
missing here?

missing ) after for-loop control
for (var i=0; ilt;feed.value.items.length; i++) {\n

getFeed() function not found

Mika



2009/2/4 Andreas Geyrecker andreas.geyrec...@gmail.com:
 Mika,

 try using a ![CDATA[ ... ]] section for your javascript code.

 see also http://www.dpawson.co.uk/xsl/sect4/N9745.html

 Andi


 2009/2/4 mikan.d.dspace listmail mikan.dsp...@gmail.com

 Im trying to add some custom Javscript code for our DSpace 1.5
 instances. The problem is though, that when compiling the source I get
 SAX errors because of '' signs on Javascript code. Should I encode
 the code somehow or how could I get around this?

 The line that causes the problem is the following:

 var addr = 'http://my.site.org/run?_render=json_callback=trythis';

 org.xml.sax.SAXParseException: The reference to entity _render must
 end with the ';' delimiter.

 context:/file:/usr/local/jetty/jetty-6.1.12rc1/webapps/dikk/themes/TDS/./../dri2xhtml/structural.xsl
 - 226:98

 Cocoon stacktrace [hide]
 The reference to entity _render must end with the ';' delimiter.

 context:/file:/usr/local/jetty/jetty-6.1.12rc1/webapps/dikk/themes/TDS/./../dri2xhtml/structural.xsl
 - 226:98

 Thanks for any tips,
 Mika


 --
 Create and Deploy Rich Internet Apps outside the browser with
 Adobe(R)AIR(TM)
 software. With Adobe AIR, Ajax developers can use existing skills and code
 to
 build responsive, highly engaging applications that combine the power of
 local
 resources and data with the reach of the web. Download the Adobe AIR SDK
 and
 Ajax docs to start building applications
 today-http://p.sf.net/sfu/adobe-com
 ___
 DSpace-tech mailing list
 DSpace-tech@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dspace-tech



--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] xmlui versus jspui

[Walker, David]

I say Manakin all the way.  Not only is the out-of-the-box design better, but 
it's significantly easier to customize (although not precisely easy), and I 
think is essentially the future of DSpace, interface-wise.

You can run both in parallel, in case you need to get to something in the jsp 
that isn't working in xmlui. But I think end users are much, much better off 
seeing only that Manaking interface.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Lyn Amery [lyn.am...@sro.wa.gov.au]
Sent: Thursday, January 08, 2009 10:43 PM
To: dspace-tech@lists.sourceforge.net
Subject: [Dspace-tech] xmlui versus jspui

I’m new to DSpace, setting up an archives repository.  I’m reasonably technical,
but not overly experienced in web development or the technologies utilised 
therein.

I’ll need to adapt DSpace to suit my agency’s needs.  As a first step, I’m 
trying
to decide whether to go with the JSP or XML (Manakin) interface.  I’ve yet to
find any discussions on what the advantages are of one to the other.  As a
newbie, would one be simpler to modify?  Are there things which one does or
doesn’t do particularly well?

Thanks for any suggestions!

Cheers,
Lyn

Lyn Amery
Web Analyst/Programmer
State Records Office
(08) 9427 3493
lyn.am...@sro.wa.gov.aumailto:lyn.am...@sro.wa.gov.au

--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Remove search box from main page

[Walker, David]

Hi Eric,

We use this.  Just at it to your local theme XSLT.

!-- remove search area on home page --
xsl:template match=dri:d...@n='front-page-search']
 xsl:apply-templates select=@pagination
 xsl:with-param name=positionbottom/xsl:with-param
 /xsl:apply-templates
/xsl:template

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Eric Luhrs [elu...@gmail.com]
Sent: Tuesday, December 16, 2008 11:46 AM
To: dspace-tech@lists.sourceforge.net
Subject: [Dspace-tech] Remove search box from main page

Hi there,
I am creating a new Manakin theme based on the Reference theme.  I
want to remove the search box that appears in the body of the main
page (not the sidebar search box).  What's the best way to do this?  I
looked at news-xmlui.xml and dri2html/*.xsl but I can't find where
this search box is being pulled from.

Eric

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] structure import problem with French and German accented characters

[Walker, David]

Hi Andrew,

I can't speak to the general question.  But on this point . . .

   uuml;

. . . is an HTML character entity reference, and is not recognized within XML 
documents in general.  To use this, you would need, as the XML parser here is 
saying, a supporting DTD entity reference declaration.

Easier, I think, maybe just to reference it using it's numeric value:

   #252;

--Dave


==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu


From: Andrew Marlow [marlow.and...@googlemail.com]
Sent: Monday, December 15, 2008 2:05 PM
To: dspace-tech@lists.sourceforge.net
Subject: [Dspace-tech] structure import problem with French and German accented 
characters


I have created an XML file for a structure import, based on a CSV file I have 
of journal titles. I am converting the CSV to XML using a bit of perl. 
Everything is fine until I introduce journal titles that contain accented 
characters. For example, one title contains the German word 'fur' with u 
umlaut. I get a UTF-8 error if I leave it like that. So in my XML file I change 
this for uuml; but it doesn't work. It says 'the entity uuml was referenced 
but not declared'. What is going wromg please? How may titles with accented 
characters be imported?
--
Regards,

Andrew M.

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] dublin core and multiple subject categorizations

[Walker, David]

Hey Andrew,

All Dublin Core fields are repeatable.  That gets mentioned here and there in 
the official DC docs and other places:

   http://www.google.com/search?q=dublin+core+repeatable

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Andrew Marlow [marlow.and...@googlemail.com]
Sent: Thursday, December 11, 2008 2:23 PM
To: dspace-tech@lists.sourceforge.net
Subject: [Dspace-tech] dublin core and multiple subject categorizations

my (limited) understanding is that in DC there is only one subject field. So 
what do people do about articles that can be categorised under multiple 
subjects? For example, I just entered an article about crystallography. The 
subject is chemistry but the subject is also crystallography. What to do?

--
Regards,

Andrew M.

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Adding Creative Commons icon to Manakin display

[Walker, David]

I'm not totally familiar with the DSpace bug tracking/resolution process, so 
excuse my ignorance here.  But should I assume it will be awhile before this 
bug gets fixed?

If so, I can think of a few work-arounds, and will get started on those.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Claudia Jürgen [EMAIL PROTECTED]
Sent: Monday, October 13, 2008 11:59 PM
To: Dorothea Salo
Cc: [EMAIL PROTECTED]
Subject: Re: [Dspace-tech] Adding Creative Commons icon to Manakin display

Hi Dorothea,

this is a known bug, see:
http://sourceforge.net/tracker/index.php?func=detailaid=2086708group_id=19984atid=119984

Sunny greetings

Claudia Jürgen


Dorothea Salo schrieb:
 Not to hijack the thread, but has anyone else noticed that clicking on
 a CC license brings up a page of HTML -- displayed as plain-text? Or
 have I done something horrible to my Manakin installation without
 meaning to?

 Dorothea

 On Mon, Oct 13, 2008 at 1:32 PM, Walker, David [EMAIL PROTECTED] wrote:
 Hi all,

 Looks like Manakin does not include the Creative Commons license icon in the 
 item display, as the older JSP pages do.

 Seems like a simple addition, but thought I would ask if anyone has done 
 this already so that I might crib their XSLT.  Thanks!

 --Dave

 ==
 David Walker
 Library Web Services Manager
 California State University
 http://xerxes.calstate.edu

 -
 This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
 Build the coolest Linux based applications with Moblin SDK  win great prizes
 Grand prize is a trip for two to an Open Source event anywhere in the world
 http://moblin-contest.org/redirect.php?banner_id=100url=/
 ___
 DSpace-tech mailing list
 DSpace-tech@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dspace-tech





-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Adding Creative Commons icon to Manakin display

[Walker, David]

Okay, if you're interested, here's a hack for this problem.  See this example:

  http://ecommons.csun.edu/northridge_xmlui/handle/10211.2/284

How it works: DSpace stores the URL of the chosen CC license in one of the 
bitstreams for the item [1].

I created an external PHP script [2] that can take that license_url bitstream 
as a parameter.  The script then calls back to DSpace, extracts the CC URL from 
the bitstream, and redirects the user to the CC site.

Finally, I updated Manakin to pass that license_url to the PHP script. [3]

--Dave

[1] 
http://ecommons.csun.edu/northridge_xmlui/bitstream/handle/10211.2/284/license_url?sequence=2

[2] http://library.calstate.edu/dspace/license/source.php

[3]

!-- creative commons workaround --

xsl:template match=mets:[EMAIL PROTECTED]'CC-LICENSE' or @USE='LICENSE']
div class=license-info
pi18n:textxmlui.dri2xhtml.METS-1.0.license-text/i18n:text/p
ul
xsl:if test=@USE='CC-LICENSE'
lia 
href=http://library.calstate.edu/dspace/license/?url=http://ecommons.csun.edu{mets:file/mets:[EMAIL
 PROTECTED]:title='license_url']/@xlink:href}Creative Commons/a/li
/xsl:if
xsl:if test=@USE='LICENSE'
lia href={mets:file/mets:[EMAIL 
PROTECTED]:title='license.txt']/@xlink:href}Original License/a/li
/xsl:if
/ul
/div
/xsl:template




==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Walker, David [EMAIL PROTECTED]
Sent: Tuesday, October 14, 2008 10:00 AM
To: Claudia Jürgen; Dorothea Salo
Cc: [EMAIL PROTECTED]
Subject: Re: [Dspace-tech] Adding Creative Commons icon to Manakin display

I'm not totally familiar with the DSpace bug tracking/resolution process, so 
excuse my ignorance here.  But should I assume it will be awhile before this 
bug gets fixed?

If so, I can think of a few work-arounds, and will get started on those.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Claudia Jürgen [EMAIL PROTECTED]
Sent: Monday, October 13, 2008 11:59 PM
To: Dorothea Salo
Cc: [EMAIL PROTECTED]
Subject: Re: [Dspace-tech] Adding Creative Commons icon to Manakin display

Hi Dorothea,

this is a known bug, see:
http://sourceforge.net/tracker/index.php?func=detailaid=2086708group_id=19984atid=119984

Sunny greetings

Claudia Jürgen


Dorothea Salo schrieb:
 Not to hijack the thread, but has anyone else noticed that clicking on
 a CC license brings up a page of HTML -- displayed as plain-text? Or
 have I done something horrible to my Manakin installation without
 meaning to?

 Dorothea

 On Mon, Oct 13, 2008 at 1:32 PM, Walker, David [EMAIL PROTECTED] wrote:
 Hi all,

 Looks like Manakin does not include the Creative Commons license icon in the 
 item display, as the older JSP pages do.

 Seems like a simple addition, but thought I would ask if anyone has done 
 this already so that I might crib their XSLT.  Thanks!

 --Dave

 ==
 David Walker
 Library Web Services Manager
 California State University
 http://xerxes.calstate.edu

 -
 This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
 Build the coolest Linux based applications with Moblin SDK  win great prizes
 Grand prize is a trip for two to an Open Source event anywhere in the world
 http://moblin-contest.org/redirect.php?banner_id=100url=/
 ___
 DSpace-tech mailing list
 DSpace-tech@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dspace-tech





-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

-
This SF.Net email is sponsored by the Moblin Your Move Developer's

[Dspace-tech] Adding Creative Commons icon to Manakin display

[Walker, David]

Hi all,

Looks like Manakin does not include the Creative Commons license icon in the 
item display, as the older JSP pages do.

Seems like a simple addition, but thought I would ask if anyone has done this 
already so that I might crib their XSLT.  Thanks!

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Adding Creative Commons icon to Manakin display

[Walker, David]

Yes, we have.  Apparently Manakin/DSpace is setting the HTTP content-type to 
text/plain here.  Firefox dutifully displays it as such, although IE sees the 
HTML and decides to display it as HTML instead of text.

Not sure how to fix that.  But it's next on my to-do list. :-)

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Dorothea Salo [EMAIL PROTECTED]
Sent: Monday, October 13, 2008 11:58 AM
To: [EMAIL PROTECTED]
Subject: Re: [Dspace-tech] Adding Creative Commons icon to Manakin display

Not to hijack the thread, but has anyone else noticed that clicking on
a CC license brings up a page of HTML -- displayed as plain-text? Or
have I done something horrible to my Manakin installation without
meaning to?

Dorothea

On Mon, Oct 13, 2008 at 1:32 PM, Walker, David [EMAIL PROTECTED] wrote:
 Hi all,

 Looks like Manakin does not include the Creative Commons license icon in the 
 item display, as the older JSP pages do.

 Seems like a simple addition, but thought I would ask if anyone has done this 
 already so that I might crib their XSLT.  Thanks!

 --Dave

 ==
 David Walker
 Library Web Services Manager
 California State University
 http://xerxes.calstate.edu

 -
 This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
 Build the coolest Linux based applications with Moblin SDK  win great prizes
 Grand prize is a trip for two to an Open Source event anywhere in the world
 http://moblin-contest.org/redirect.php?banner_id=100url=/
 ___
 DSpace-tech mailing list
 DSpace-tech@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dspace-tech




--
Dorothea Salo[EMAIL PROTECTED]
Digital Repository Librarian  AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Manakin: Why am I getting a doubled header?

[Walker, David]

 Your sites down, so I can't view your example.

Sorry, bad timing with a hardware upgrade.  Back now.  :-)

  http://scholarworks.calstate.edu/scholarworks_xmlui/handle/123456789/5

As you can see, Dorthea's template renders this element as it should -- or at 
least without the duplicate definition term.  So that makes me think that the 
problem lies outside this template.

 I just think your messages.xml labels are different

Sorry, I was unclear before.  I mean the actual keys, rather than just the 
labels, are different -- maybe because this is a pre-1.5 messages.xml ?  That 
probably makes no difference.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Mark Diggory [EMAIL PROTECTED] On Behalf Of Mark Diggory [EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 4:55 PM
To: Walker, David
Cc: Dorothea Salo; dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] Manakin: Why am I getting a doubled header?

I just think your messages.xml labels are different. the generated
html is the same and I bet the length of the value causes yours to
wrap to the line above. Your sites down, so I can't view your example.

Dorothea, could you just drop your war on a url somewhere and send it
to me... I'll look at it on my workstation.

-Mark


On Sep 24, 2008, at 4:43 PM, Walker, David wrote:

 I don't think that's it, Mark, because the same template works in
 our test instance, even with the dd /.

 http://scholarworks.calstate.edu/scholarworks_xmlui/handle/123456789/5

 dtThis item appears in the following Collection(s)/dt
 dd /
 dtPart of/dt
 ddhttp://www.aip.org; http://apl.aip.org//dd

 I also don't get those i18n namespaces in the resulting output, as
 Dorthea does.  I also notice that some of the labels in the
 utils.xsl template are (slightly) different from the ones in the
 messages.xml file in out newly installed 1.5 instance.  Not sure
 what that means, honestly, just thought I'd mention it.

 --Dave

 ==
 David Walker
 Library Web Services Manager
 California State University
 http://xerxes.calstate.edu
 
 From: Mark Diggory [EMAIL PROTECTED]
 Sent: Wednesday, September 24, 2008 2:40 PM
 To: Dorothea Salo
 Cc: dspace-tech@lists.sourceforge.net
 Subject: Re: [Dspace-tech] Manakin: Why am I getting a doubled header?

 I believe its the section above...
 xmlui.ArtifactBrowser.ItemViewer.head_parent_collections creates
 the same label and your dd doesn't create any body, which closes it
 out (dd/) and breaks the flow.

   !-- Kill the fields if they're empty. -DS --
 dt

 i18n:textxmlui.ArtifactBrowser.ItemViewer.head_parent_collections/
 i
 18n:text
 /dt

 dd
 xsl:for-each
 select=/dri:document/dri:body/dri:div/
 dri:referenceSet
 [EMAIL PROTECTED]'aspect.artifactbrowser.ItemViewer.referenceSet.collection-
 viewer' and @n='collection-viewer']/dri:reference
 xsl:apply-templates
 select=/dri:document/dri:body/dri:div/
 dri:referenceSet
 [EMAIL PROTECTED]'aspect.artifactbrowser.ItemViewer.referenceSet.collection-
 viewer'and @n='collection-viewer']/dri:reference
 mode=render/
 xsl:if test=count(following-
 sibling::dri:reference) != 0
 xsl:text; /xsl:text
 /xsl:if
 /xsl:for-each
 /dd



 On Sep 24, 2008, at 1:40 PM, Dorothea Salo wrote:

 I wonder if we have enough XSL context to see the problem.

 The utilities template is available from
 http://minds-test.wisconsin.edu/themes/utils.xsl, and the UW-
 Madison
 theme that inherits this theme is at
 http://minds-test.wisconsin.edu/themes/UWMadison/uwmadison.xsl.
 Share and enjoy!

 (Not that I'm anything like an XSL wizard, but this looks like a
 good
 learning opportunity and, who knows? I might solve it.)

 The empty 'dd' really draws my attention but I can't yet see how it
 happens.

 Oh, good, it's not just me! I'm baffled and feeling ungodly stupid
 that I can't seem to solve this (especially when the same technique
 seems to work FINE for authors!).

 Dorothea

 --
 Dorothea Salo [EMAIL PROTECTED]
 Digital Repository Librarian AIM: mindsatuw
 University of Wisconsin
 Rm 218, Memorial Library
 (608) 262-5493

 -
 -
 ---
 This SF.Net email is sponsored by the Moblin Your Move Developer's
 challenge
 Build the coolest Linux based applications with Moblin SDK  win
 great prizes
 Grand prize is a trip for two to an Open Source event anywhere in
 the world
 http://moblin-contest.org/redirect.php?banner_id=100url=/
 ___
 DSpace-tech mailing list
 DSpace-tech@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Manakin: Why am I getting a doubled header?

[Walker, David]

I don't think that's it, Mark, because the same template works in our test 
instance, even with the dd /.

http://scholarworks.calstate.edu/scholarworks_xmlui/handle/123456789/5

dtThis item appears in the following Collection(s)/dt
dd /
dtPart of/dt
ddhttp://www.aip.org; http://apl.aip.org//dd

I also don't get those i18n namespaces in the resulting output, as Dorthea 
does.  I also notice that some of the labels in the utils.xsl template are 
(slightly) different from the ones in the messages.xml file in out newly 
installed 1.5 instance.  Not sure what that means, honestly, just thought I'd 
mention it.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Mark Diggory [EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 2:40 PM
To: Dorothea Salo
Cc: dspace-tech@lists.sourceforge.net
Subject: Re: [Dspace-tech] Manakin: Why am I getting a doubled header?

I believe its the section above...
xmlui.ArtifactBrowser.ItemViewer.head_parent_collections creates
the same label and your dd doesn't create any body, which closes it
out (dd/) and breaks the flow.

   !-- Kill the fields if they're empty. -DS --
 dt

 i18n:textxmlui.ArtifactBrowser.ItemViewer.head_parent_collections/i
 18n:text
 /dt

 dd
 xsl:for-each
 select=/dri:document/dri:body/dri:div/
 dri:referenceSet
 [EMAIL PROTECTED]'aspect.artifactbrowser.ItemViewer.referenceSet.collection-
 viewer' and @n='collection-viewer']/dri:reference
 xsl:apply-templates
 select=/dri:document/dri:body/dri:div/
 dri:referenceSet
 [EMAIL PROTECTED]'aspect.artifactbrowser.ItemViewer.referenceSet.collection-
 viewer'and @n='collection-viewer']/dri:reference
 mode=render/
 xsl:if test=count(following-
 sibling::dri:reference) != 0
 xsl:text; /xsl:text
 /xsl:if
 /xsl:for-each
 /dd



On Sep 24, 2008, at 1:40 PM, Dorothea Salo wrote:

 I wonder if we have enough XSL context to see the problem.

 The utilities template is available from
 http://minds-test.wisconsin.edu/themes/utils.xsl, and the UW-Madison
 theme that inherits this theme is at
 http://minds-test.wisconsin.edu/themes/UWMadison/uwmadison.xsl.
 Share and enjoy!

 (Not that I'm anything like an XSL wizard, but this looks like a good
 learning opportunity and, who knows? I might solve it.)

 The empty 'dd' really draws my attention but I can't yet see how it
 happens.

 Oh, good, it's not just me! I'm baffled and feeling ungodly stupid
 that I can't seem to solve this (especially when the same technique
 seems to work FINE for authors!).

 Dorothea

 --
 Dorothea Salo [EMAIL PROTECTED]
 Digital Repository Librarian AIM: mindsatuw
 University of Wisconsin
 Rm 218, Memorial Library
 (608) 262-5493

 --
 ---
 This SF.Net email is sponsored by the Moblin Your Move Developer's
 challenge
 Build the coolest Linux based applications with Moblin SDK  win
 great prizes
 Grand prize is a trip for two to an Open Source event anywhere in
 the world
 http://moblin-contest.org/redirect.php?banner_id=100url=/
 ___
 DSpace-tech mailing list
 DSpace-tech@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dspace-tech

~
Mark R. Diggory - DSpace Developer and Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology
Home Page: http://purl.org/net/mdiggory/homepage






-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] xsl match to own metadata

[Walker, David]

If you append ?XML to the URL of your DSpace instance, Michael, do you see your 
custom fields in the XML response?  
 
If so, then you should be able to more or less copy the pattern below, changing 
it match those field.
 
--Dave
 
---
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu



From: [EMAIL PROTECTED] on behalf of Michael Steck
Sent: Tue 6/17/2008 5:59 AM
Cc: dspace-tech@lists.sourceforge.net
Subject: [Dspace-tech] xsl match to own metadata



hi there,

i am coding at my own theme template.xsl and wonder how i can select my
own metadata fields.

that is the way i request the dc.fields (for example)

xsl:for-each select=dim:[EMAIL PROTECTED]'identifier' and
@qualifier='citation']
   xsl:copy-of select=node() /
...

but what do i have to do to select my individual field
(myfield.comment.comment)


thanks,



--
Dipl.- Ing. Michael Steck
FfE - Forschungsstelle für Energiewirtschaft e.V.
Am Blütenanger 71
80995 München
Tel.: 089/158121-22
Fax: 089/158121-10
[EMAIL PROTECTED]
www.ffe.de
--


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

[Dspace-tech] Manakin heading problems

[Walker, David]

Hi all,
 
I have a problem I'm hoping someone else has already fixed: Headings (h1, h2, 
etc.) don't always follow a correct hierarchy in Manakin.
 
Some pages -- for example, the home page -- include multiple h1's [1].  Others 
include headings that skip from h1 to h3 without an intervening h2 [2].  This 
violate one of our ADA/accessibility requirements.
 
There are a couple of different templates that set headings in Manakin, but the 
one that seems to be causing us problems is the dynamic one, here:
 
 xsl:template match=dri:div/dri:head priority=3
   xsl:variable name=head_count select=count(ancestor::dri:div)/
   xsl:element name=h{$head_count}
   [...]
 /xsl:template
 
Has anyone addressed this problem already?
 
--Dave
 
 
These examples from the Texas AM Manakin, although it is true of all the 
implementations I've seen:
 
[1] http://repositories.tamu.edu/
 
[2] http://repositories.tamu.edu/community-list
 
---
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Re: [Dspace-tech] Help with Manakin theme debugging

[Walker, David]

Hey Dorthea,
 
The problem appears to be that these 'bad' pages end-up creating a collapsed, 
empty detail-view layer, like this:
 
  div class=detail-view /
 
For some reason, that is causing Firefox to misbehave.  If I copy your HTML 
source to a local file and edit this line to this, it works fine:
 
  div class=detail-view/div
 
The 'bad' collections don't seem to have an into or copyright text, hence this 
layer being empty.  
 
The original Manakin template in DS-METS-1.0-DOM.xsl includes a non-breaking 
space (#160;) after the div, which would guarantee at least some data in that 
layer.  Did you perhaps remove that in your theme?  If so, restoring it might 
at least confirm my hypothesis.  
 
Also, your pages don't seem to display in IE.  Is that just me?  Perhaps the 
conditional [ie] tag is not closed or something?
 
--Dave
 
---
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu



From: [EMAIL PROTECTED] on behalf of Dorothea Salo
Sent: Tue 2/5/2008 11:04 AM
To: dspace-tech@lists.sourceforge.net
Subject: [Dspace-tech] Help with Manakin theme debugging



Okay, I am admitting defeat. I cannot get one particular Manakin theme
working on all pages, and I can't figure out why not.

Broken page in theme:
http://minds-test.wisconsin.edu/manakin/handle/1960/10498
Another broken page in theme:
http://minds-test.wisconsin.edu/manakin/handle/1960/208
Working page in theme: http://minds-test.wisconsin.edu/manakin/handle/1960/122

Here's the code that governs the basic structure of the page. What
appears to be happening is that the so-called goodies boxes end up
nested incorrectly for no readily apparent reason. I know that the
variables work as intended; I've got them in place on another theme.

Whoever solves this is entitled to a night out with me paying for all
their beverages, at the next conference we both attend. I am
completely stuck. I'll be happy to forward the entire theme if that
will help.

xsl:template match=dri:document
html

!-- First of all, build the HTML head element --
xsl:call-template name=buildHead/
!-- Then proceed to the body --
body
div id=wrapper
!--
The header div, complete with title, subtitle,
trail and other junk. The trail is
built by applying a template over pageMeta's
trail children. --
xsl:call-template name=buildHeader/
xsl:call-template name=buildOptions /
!--
Goes over the document tag's children
elements: body, options, meta. The body template
generates the ds-body div that contains all
the content. The options template generates
the ds-options div that contains the
navigation and action options available to the
user. The meta element is ignored since its
contents are not processed directly, but
instead referenced from the different points
in the document. --
div id=content-wrapper
xsl:if test=$is_comm or $is_coll
xsl:attribute
name=classwith-goodies-box/xsl:attribute
/xsl:if
div id=content
xsl:apply-templates /
/div
xsl:if test=$is_coll or $is_comm
xsl:call-template name=goodienav/
xsl:call-template name=goodieabout/
xsl:call-template name=goodiedeposit/
/xsl:if
/div

xsl:call-template name=buildFooter/
/div

/body
/html
/xsl:template

--
Dorothea Salo[EMAIL PROTECTED]
Digital Repository Librarian  AIM: mindsatuw
University of Wisconsin
Rm 218, Memorial Library
(608) 262-5493

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech