See also: http://www.w3schools.com/xsl/default.asp
Yves Barbion Documentation Architect Adobe-Certified FrameMaker Instructor ____________________________________ Scripto bvba Asselsstraat 65 9031 Gent Belgium T: +32 494 12 01 89 F: +32 9 366 50 32 BTW (VAT) BE 0886.192.394 skype: yves.barbion ____________________________________ Mike Feimster wrote: > Carrie > > XSLT is short for Extensible Stylesheet Language Transformations . It is > a programming language used to transform XML from one syntax to HTML, > plain text, or another XML syntax, etc. > > For example. Lets say you have an XML file that looks like this: > > <Document> > <Heading>Hello World</Heading> > <Paragraph>Lorem Ipsum . . .</Paragraph> > </Document> > > You can use XSLT to transform it to the following HTML: > > <html> > ... > <body> > <h1>Hello World</h1> > <p>Lorem Ipsum . . .</p> > </body> > </html> > > This is an XML technology, not a structured Frame technology, but you > can incorporate it with structured Frame. > > Mike > > -----Original Message----- > From: > framers-bounces+mike.feimster=acstechnologies.com at lists.frameusers.com > [mailto:framers-bounces+mike.feimster=acstechnologies.com at lists.frameuse > rs.com] On Behalf Of Carrie Baker > Sent: Monday, May 21, 2007 1:08 PM > To: Scott Prentice > Cc: framers at lists.frameusers.com > Subject: Re: Getting data from xml into Frame was,Do I need to jump into > the Structured FM pool? > > As I hoped I am getting some interesting answers. > However, since I have not worked on structured Frame yet, and am not > so famailiar with the terminology, can you explain was an XSLT > transformation is? > > On 5/21/07, Scott Prentice <sp at leximation.com> wrote: > >> Hi Carrie... >> >> For starters, you should get ahold of an XML diff tool (just google >> > "xml > >> diff", and you'll see lots of options) so you can determine exactly >> > what > >> has changed between versions of this XML file. You should be able to >> > get > >> one of your developers to write an XSLT transformation that would >> generate a list of the parameters in the file, and you can compare >> > that > >> list to a "TOC" list generated from your Frame file .. this will let >> > you > >> determine what's missing or extra. >> >> In an ideal world, you might consider authoring the "descriptions" of >> the parameters and fields in XML (in Frame or another XML editor), >> > then > >> run an XSLT transformation on the "descriptions" file and the file >> provided by development to generate the source for your final >> documentation. You'd just open the generated file in Frame (after >> setting up a structure application), and it would be ready to print. >> > The > >> EDD could be set up to render any missing descriptions with a big red >> "MISSING DESCRIPTION" note, in which case you'd add that to the >> descriptions file and regenerate. >> >> Obviously this would take some time and money to set up, but in the >> > long > >> run will probably save a lot. Just having the ability to easily diff >> > the > >> versions of the XML file will probably be a big improvement though. >> >> Good luck! >> >> ...scott >> >> Scott Prentice >> Leximation, Inc. >> www.leximation.com >> +1.415.485.1892 >> >> >> >> Carrie Baker wrote: >> >>> Slightly connected to this. >>> We have Frame 7.2, not structured and are doing fine. >>> We are a small (understaffed) department of 2 half time writers. >>> There is one very large chapter of a user guide which is based on >>> information from the programmers .xml file. >>> Their xml file consists of a list of parameters with various >>> explanations about them. This file is used by the application. >>> As writers we need to list all of these parameters and explain them. >>> Documentation began when the list was a very small list. The SME >>> > gave > >>> us a word file which was eventually converted to Frame with the >>> information the users required. >>> Since then everything has grown a lot. >>> The xml file now contains a over 2000 parameters. >>> Various tech writers worked on it over the years and at some point a >>> lot of parameters were missed out. >>> For every product release a large number of parameters are added to >>> the list. >>> The problem I am facing is how to identify the parameters that are >>> currently missing from the Frame file, and in the future how to >>> smoothly make sure the file is kept up to date. As new features are >>> developed R&D tell us which parameters are added, but if parameters >>> are changed or removed we do not really have a way of tracking. >>> R&D tried to give us an Excel file (i.e. they opened their xml file >>> > in > >>> Excel and saved it for us....), but it actually messed up the >>> information, since there were also sub groups of parameters (e.g. >>> parameter x contains the following 50 fields, then each field >>> > appeared > >>> as a stand alone parameter). >>> >>> As is mentioned below, Frame knows how to talk to xml, so what I am >>> looking for is whether someone can tell me, how I can make my >>> alphabetical list in FrameMaker (which I am willing to turn into a >>> table or something else), talk directly to the xml list to see what >>> > is > >>> missing from my list and in future easily identify what to add. >>> However, the entire content of the 2 lists are not identical, since >>> the Frame file (or user guide) has to give the user a full >>> > explanation > >>> of the meaning of each parameter, which the .xml file does not do. >>> >>> (or what can I ask R&D to do to help us, as each time they only give >>> us this messed up Excel file) >>> >>> (Oh and my boss does not want to spend too much time on this!) >>> >>> > ______________________________________________________________________ > >>> Marcus wrote >>> >>> "Structure can certainly help - if you store your manuals in XML all >>> > the > >>> manual work can be eliminated. Chances are your bug tracking system >>> > can > >>> export reports in XML. An XSLT stylesheet can very easily replace >>> > the > >>> existing version of this information so when next you open the >>> document in >>> FrameMaker, the data is all updated. >>> >>> Of course, this open up myriad possibilities for customisation of >>> > the bug > >>> information - separation of code and interface bugs, ordering by >>> > severity > >>> for developers and date for managers, whatever you can imagine. >>> >>> The point is that generating this information is best accomplished >>> > by > >>> your >>> bug tracking software, not by FrameMaker. It can generate a report >>> > of > >>> open >>> bugs, so why would you want to do exactly that in FrameMaker? You >>> > may > >>> want >>> to dump it all into FrameMaker and conditionally display it - >>> > providing > >>> different views for different audiences is very much part of what >>> FrameMaker should be responsible for. >>> >>> Probably the biggest gain that you can get out of XML is the ability >>> > to > >>> make your information span applications, but to do so you obviously >>> > need > >>> to look wider than FrameMaker. You're doing software manuals by the >>> > sound > >>> of it, so you presumably have access to programmers. If I was you, >>> > the > >>> first step would be sit down with a couple of them and see if you >>> > have > >>> the >>> resources to develop a scalable, robust system. I recommend against >>> > the > >>> "toe in the water" approach - I've seen too many people spending too >>> > much > >>> time trying to gradually improve them into the system that they knew >>> > they > >>> wanted but weren't brave enough to embark on in the first place. >>> >>> Measure twice, cut once and have fun!" >>> >>> >>> Marcus >>> _____________________________________________________________ >>> Carrie Baker >>> carriebak at gmail.com >>> >>> >> > > >
