[Yanel-usage] More on Docbook, protocols, & CSS

Michael Wechner michael.wechner at wyona.com
Tue May 27 08:54:20 CEST 2008


Mike Weiss wrote:

>
>
> yanel-usage-request at wyona.com wrote:
>
>>Message: 1
>>Date: Mon, 26 May 2008 07:49:34 +0200
>>From: Michael Wechner <michael.wechner at wyona.com>
>>Subject: Re: [Yanel-usage] More on Docbook Xinclude
>>To: yanel-usage at wyona.com
>>Message-ID: <483A4F6E.1050407 at wyona.com>
>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>>simon litwan wrote:
>>
>>  
>>
>>>Mike W schrieb:
>>>
>>>    
>>>
>>>>Michael,
>>>>
>>>>Looks like the "VERSION" reference in the error below indicates that 
>>>>the transform is failing at the first Xinclude in the XSL file. That 
>>>>reference had a relative path ("../VERSION") so I commented it out 
>>>>and it failed on the next Xinclude which was in the current directory 
>>>>("param.xsl). So it looks like there is a problem with Xincludes? The 
>>>>Docbook XSL has a lot of them...
>>>>      
>>>>
>>>hi mike
>>>
>>>not sure i'm on the right track, but.
>>>first i think the problem are the relative path. to what are they 
>>>relative. where do you store the files this references are pointing 
>>>to. you could store them in your realms data-repo for now.
>>>
>>>maybe it would make sense in the future to make a docbook 
>>>resource-type which then could contain the files the xsl is including.
>>>    
>>>
>>
>>
>>agreed, whereas one could extend the XML resource and not much 
>>programming would be required
>>  
>>
> A good idea but there is a problem...the DB XSL does get updated from 
> time to time and therefore it would be better to detach the XSL. The 
> ability to plug in the XSL without having to change the <xsl:include> 
> statements would be even best-- in other words, removing the need for 
> a protocol. Most DB-XSL implementations (ant pipelines, etc) use a 
> "customization layer" that enables the user to leave the XSL 
> untouched, only modifying the customization files.


very much agreed, whereas it's actually two-fold:

- The dedicated resource would help to reuse the docbook XSLTs without 
having to copy them from one realm into the other and hence no need to 
duplicate them (but yes this doesn't fix the problem you are describing)

- The protocol issue can be solved by improving the java class

          src/core/java/org/wyona/yanel/core/source/SourceResolver.java

which is used in

          src/impl/java/org/wyona/yanel/impl/resources/BasicXMLResource.java

by setting the SourceResolver of the TransformerFactory

          tf.setURIResolver(uriResolver);


I think we just need to slightly enhance the SourceResolver by 
implementing a fallback to the yanelrepo scheme if not scheme is available

Does anyone see a problem with this?

>>  
>>
>>>but for now just put them in the data-repo of your realm.
>>>
>>>then you need to add a protocol scheme in front of the xinclude path.
>>>    
>>>
>>
>>
>>I don't think so, because if you don't specify a scheme it will fallback 
>>to yanelrepo:/
>>
>>  
>>
>>>if you store the files your xsl is including within the data-repo of 
>>>your realm the files will be accessible via the yanelrepo:/ schema.
>>>
>>>BTW i couldn't find the docu regarding source protocols. is there one?
>>>    
>>>
>>
>>
>>yes, at
>>
>>http://documentation.yanel.wyona.org/Wiki.jsp?page=Unstructured%20Points
>>
>>Different schemes to access repository 
>><http://documentation.yanel.wyona.org/Edit.jsp?page=Different%20schemes%20to%20access%20repository> 
>>There are several ways to access data within Yanel:
>>
>>   1. Through the URL that will finally to a resource configuration:
>>      http://.../yanel/myrealm/index.html -> index.html.yanel-rc
>>   2. Through *yanelresource* scheme that allows to bypass HTTP:
>>      yanelresource:/index.html -> index.html.yanel.rc
>>   3. Through *yanelrepo* scheme that directly accesses the repository:
>>      yanelrepo:/index.html -> /data/index.html
>>   4. Through *yanelrepo* scheme that directly accesses the repository:
>>      yanelrepo:REALM_ID:/index.html -> /data/index.html
>>   5. Through *yanelrepo* scheme that directly accesses the repository:
>>      yanelrepo:REALM_ID:REPO_ID:/index.html -> /data/index.html
>>
>>
>>  
>>
>>>otherwise we have to add something about the protocol scheme to the docu.
>>>    
>>>
>>
>>
>>it would be great to merge this into the website documentation. Would 
>>you, could you ;-) ?
>>
>>Cheers
>>
>>Michael
>>
>>  
>>
> Michael, if you're talking to me here...that's no problem, just set me 
> up with what I need and I will add this to the web documentation.


I was actually "talking" to Simon ;-), but it would be great of course 
if you could help as well

> I will also re-org and update content as I learn more and as I have 
> time available in the coming months.
>
> At this point I have been unable to render DB XSL in Yanel


I think we will be able to fix this shortly

> or Yulup. Even when it (eventually) becomes possible, it will take an 
> extraordinary amount of time to render on-the-fly in either tool.


well, we could do some caching, but this of course only really helps if 
the content hasn't changed

> So it occured to me...is it or would it be possible to render DB using 
> CSS directly? I've read that most browsers are capable of this now. 
> CSS would be a good intermediary for editing,


what editor for this are you amining at?

> while a pipeline could be used later for generating XHTML, PDF using XSL.


right

Cheers

Michael

>
>------------------------------------------------------------------------
>
>_______________________________________________
>Yanel-usage mailing list
>Yanel-usage at wyona.com
>http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-usage
>  
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management - Yanel, Yulup
http://www.wyona.com
michael.wechner at wyona.com, michi at apache.org
+41 44 272 91 61



More information about the Yanel-usage mailing list