[
Lists Home |
Date Index |
Thread Index
]
Hi.
The XSL is not complete. There's a mistake in the xpath in the document
function. There may be other mistakes as well. This is simplified
prototype code... If it does not adequately illustrate the point I can
try to expand on it, let me know!!
----->N
.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:
||:.
Nathan Young
CDC Site Dev->Interface Development Team
A: ncy1717
E: natyoung@cisco.com
> -----Original Message-----
> From: Nathan Young -X (natyoung - Artizen at Cisco)
> Sent: Tuesday, February 21, 2006 11:22 AM
> To: Peter Hunsberger; publicreg@nascencetech.com
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Implementing an Blogger-style template
> using XSLT
>
> Hi.
>
> I second the assertion that XSL and XML work great for implementing
> lightweight custom templating languages.
>
> My interpretation of what you want to do differs from Terence's. I
> think what you want is to have an XML (XHTML + custom namespace)
> template marked up with placeholders, and an XML file full of
> values for
> those placeholders. Then an XSL to merge the two.
>
> I think I remember Jenni Tennison even had a name for this as a design
> pattern but I can't recall what it was.
>
> In any case, if this is what you want, it's similar to a solution I
> posted to the XSL list a while ago for localization. Simplified:
>
> The XHTML templates with placeholders look like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <html xmlns="http://www.w3.org/1999/xhtml";
> xmlns:ln="http://example.com/ln";> <body>
> <ln:translateterm key="greeting"/>, <ln:translateterm
> key="appelation"/> give me 100 <ln:translateterm key="currency"/>
> </body>
> </html>
>
> The XML that holds values for the placeholders looks like this:
>
> <?xml version="1.0"?>
> <dictionary>
> <translateterm key="greeting">Hey</translateterm>
> <translateterm key="appelation">person</translateterm>
> <translateterm key="currency">dollars</translateterm>
> </dictionary>
>
> The XSL transforms the template and looks like:
>
> <!-- get the values for the placeholders from an external XML
> file -->
> <xsl:param name="dictName" />
> <xsl:variable name="dictionary"
> select="document($dictName)/dictionary/bundle[@language=$language]"/>
>
> <!-- copy everything through as is -->
> <xsl:template match="/ | @* | node()">
> <xsl:copy>
> <xsl:apply-templates select="@* | node()"/>
> </xsl:copy>
> </xsl:template>
>
> <!-- except placeholders which get replaced with values -->
> <xsl:template match="ln:translateterm">
> <xsl:variable name="keyToFind" select="@key"/>
> <xsl:value-of
> select="$dictionary/translateterm[@key=$keyToFind]"/>
> </xsl:template>
>
>
> ------------->Nathan
>
>
> > -----Original Message-----
> > From: Nathan Young -X (natyoung - Artizen at Cisco)
> > Sent: Wednesday, February 01, 2006 12:31 PM
> > To: 'xsl-list@lists.mulberrytech.com'
> > Subject: RE: [xsl] Language-specific output
> >
> > Hi.
> >
> > Our systems are all still tied to XSL 1.0 (with no nodeset
> > extensions) so I can't use variables the way you do in your example.
> >
> > Instead we use the document function to get what we call the
> > dictionary.
> >
> > The language specific values are stored in an xml file:
> >
> > <dictionary>
> > <bundle language="english">
> > <term key="TTitle">XMP Abstract for the file</term>
> > ... other english terms
> > </bundle>
> > <bundle language="german">
> > <term key="TTitle">XMP Steckbrief der Datei</term>
> > ... other german terms
> > </bundle>
> > </dictionary>
> >
> >
> > Then at the top of your XSL:
> >
> > <xsl:param name="language"/>
> > <xsl:variable name="dictionary"
> > select="document('path/to/dictionary/xml')/dictionary/bundle[@
> > language=$language]"/>
> >
> > Then to get the values:
> >
> > <xsl:value-of select="$dictionary/term[@key='TTitle']"/>
> >
> > Terms of course could have more complex structure as needed.
> >
> >
> > ------------->Nathan
> >
> >
> > .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.
> > _.:||:._.:||:.
> >
> > Nathan Young
> > CDC Site Dev->Interface Development Team
> > A: ncy1717
> > E: natyoung@cisco.com
> >
> > > -----Original Message-----
> > > From: cavecatem@directbox.com [mailto:cavecatem@directbox.com]
> > > Sent: Wednesday, February 01, 2006 7:32 AM
> > > To: xsl-list@lists.mulberrytech.com
> > > Subject: [xsl] Language-specific output
> > >
> > > Hi all,
> > >
> > > I'm working on a stylesheet that transforms XMP-data to a
> > > nicely layouted HTML file.
> > > I'm working with oxygen and saxon8b (i.e. XSLT 2.0).
> > > Unfortunately, there is the problem of internationalisation,
> > > i.e. we have to be able to create at least a German an
> > > English version of the HTML file.
> > >
> > > I'm still new to practicing my XML/XSLT-skills so my problems
> > > might simply arise from lack of practice. I didn't find an
> > > answer when looking in the list archive, though.
> > >
> > > Rather than maintain two language versions of the stylesheet,
> > > I thought I could try variables in an external file:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <xsl:stylesheet
> > > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; version="2.0">
> > > <xsl:variable name="TFilename">
> > > <a lang="de">Datei: </a>
> > > <a lang="en">File: </a>
> > > </xsl:variable>
> > > <xsl:variable name="TTitle">
> > > <a lang="de">XMP Steckbrief der Datei </a>
> > > <a lang="en">XMP Abstract for the file </a>
> > > </xsl:variable>
> > > <xsl:variable name="TExifTitle">
> > > <a lang="de">EXIF-Daten</a>
> > > <a lang="en">EXIF-Data</a>
> > > </xsl:variable>
> > > <xsl:variable name="TExposureTime">
> > > <a lang="de">Belichtungszeit [s]</a>
> > > <a lang="en">Exposure time [s]</a>
> > > </xsl:variable>
> > >
> > > <xsl:variable name="lightsource">
> > > <a code="1">
> > > <a lang="de">unbekannt</a>
> > > <a lang="en">unknown>/a>
> > > </a>
> > > <a code="1">
> > > <a lang="de">Tageslicht</a>
> > > <a lang="en">Artificial</a>
> > > <a>
> > > ...
> > > </xsl:variable>
> > >
> > > So I call the normal variables
> > > with <xsl:value-of select="$variablename/a [@lang = $lang] />
> > > and the complex ones with
> > > with <xsl:value-of select="$variablename/a [@code = $code]/a
> > > [@lang = $lang] />
> > >
> > >
> > > It was a bit tricky to get around the xsl:include/xsl:import
> > > problem, as the stylesheets are modular and my parser
> > > insisted that I have to include/import the external file into
> > > all sub-stylesheets which then in turn leads to problems with
> > > precedence.
> > >
> > > Three questions actually:
> > >
> > > 1. Why does the parser insist on me declaring the variables
> > > in each separate stylesheet, when he works on the parent
> > > stylesheet where the text variable stylesheet is incuded as a
> > > top-level element?
> > > The same doesn't happen with <xsl:param name=lang> which is
> > > only declared in the top level stylesheet.
> > >
> > > 2. Someone metionend a while ago that it is better to avoid
> > > variables as they create result tree fragments. Is there a
> > > better way to do this?
> > >
> > > 3. The XMP data sometimes contains language-sepcific data in
> > > elements of the type lang alt, e.g.
> > >
> > > <dc:description>
> > > <rdf:Alt>
> > > <rdf:li xml:lang="x-default">Pferde bei der
> > > Bachueberquerung</rdf:li>
> > > <rdf:li xml:lang="en">Horses crossing a
> > stream</rdf:li>
> > > </rdf:Alt>
> > >
> > > Is there a way to get either my specified language or - if
> > > that is not present - the 'language' x-default?
> > >
> > > The following works but doing this for a lot of elements
> > > makes it rather slow.
> > > ($lang is passed as a global parameter when saxon is called)
> > >
> > > <xsl:choose>
> > > <xsl:when
> > > test="rdf:Description/dc:rights/rdf:Alt/rdf:li/@xml:lang = $lang">
> > > <xsl:value-of
> > > select="rdf:Description/dc:rights/rdf:Alt/rdf:li[@xml:lang
> > = $lang]"/>
> > > </xsl:when>
> > > <xsl:otherwise>
> > > <xsl:value-of
> > > select="rdf:Description/dc:rights/rdf:Alt/rdf:li[@xml:lang
> > > = 'x-default']"/>
> > > </xsl:otherwise>
> > > </xsl:choose>
> > >
> > >
> > > Thanks for any suggestions that might help.
> > >
> > > Regards
> > > CJ
> > >
> > >
> > >
> > >
> >
> --~------------------------------------------------------------------
> > > XSL-List info and archive:
> http://www.mulberrytech.com/xsl/xsl-list
> > > To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
> > > or e-mail: <mailto:xsl-list-unsubscribe@lists.mulberrytech.com>
> > > --~--
> > >
>
>
>
> .:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.
> _.:||:._.:
> ||:.
>
> Nathan Young
> CDC Site Dev->Interface Development Team
> A: ncy1717
> E: natyoung@cisco.com
>
> > -----Original Message-----
> > From: Peter Hunsberger [mailto:peter.hunsberger@gmail.com]
> > Sent: Tuesday, February 21, 2006 6:33 AM
> > To: publicreg@nascencetech.com
> > Cc: xml-dev@lists.xml.org
> > Subject: Re: [xml-dev] Implementing an Blogger-style template
> > using XSLT
> >
> > On 2/21/06, publicreg@nascencetech.com
> > <publicreg@nascencetech.com> wrote:
> > > Hi,
> > >
> > > I'm trying to implement a Blogger-style templating system
> > and would like
> > > to get some feedback on whether it's feasible or not. While
> > it's true that
> > > an XSLT file itself would be a template, some of my users
> > are not keen on
> > > learning it and I'm trying to strike some middle ground here.
> > >
> > > The premise is this:
> > >
> > > The template file would be an extension of XHTML and looks
> > like this:
> > >
> > <snip/> -------------------------
> > >
> > > Then, the data input would come in the form of an XML
> > document that looks
> > > like this:
> > >
> > ><snip/> --------------------------
> > >
> > >
> > > Finally, I'd have an XSLT file that uses the 2 files and
> > then translates
> > > into XHTML code that I can output to the browser.
> > >
> > > How, folks? Do you think it's feasible to do this? Would
> > appreciate any
> > > pointers in the right direction.
> >
> > I've used essentially this architecture since the days when XSLT was
> > still a draft standard. It works very well and with proper
> design can
> > have good performance. (Proper design includes many forms
> of caching.)
> >
> > Currently we use Apache Cocoon to drive this which gives us a lot of
> > capabilities, many of which we don't really exploit. It's
> probably at
> > least worth looking at. In particular you can exploit pipelines to
> > break complex XSLT down into multiple transformations which often
> > makes hard XSLT problems a lot easier to code (you don't
> have to build
> > up complex variables and re-parse them for some problems)
> and you can
> > aggregate multiple XML sources to make context sensitive
> parsing much
> > easier.
> >
> > Depending on your eventual deployment targets (cell phones, print,
> > other devices?) you may want to go a little more abstract than XHTML
> > for your mark up language. XUL, XFORMS or something proprietary
> > perhaps.Among other things you might be able to keep the language
> > simpler and easier for the end users; and you can maybe separate the
> > presentation details from the markup model.
> >
> > In our case we use a very abstract model and two main XSLT passes.
> > The first creates an abstract combined model from the layout model,
> > the data, authorizations and other context dependant things (eg. do
> > you need internationalization support?). The output of smashing all
> > these things together is still an abstract object model,
> but one that
> > maps pretty directly to output, minus any presentation
> device specific
> > details. Depending on the deployment target a second transformation
> > then takes care of the specific presentation details.
> >
> > I'd note that you should also plan on exploiting the capabilities of
> > CSS. Depending on your needs it might be possible to do
> everything in
> > pure XML and CSS in which case things can be a lot simpler.
> >
> >
> > --
> > Peter Hunsberger
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://www.oasis-open.org/mlmanage/index.php>
> >
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
|
