Loading ...
Sorry, an error occurred while loading the content.

Re: [XSL-FO] XSL-FO

Expand Messages
  • Peter Wu
    Hmmm...this is interesting. Elliott, if I understand what you are saying, it s really up to the Xforms community to support FO format semantics. So instead of
    Message 1 of 19 , Oct 20, 2005
    • 0 Attachment
      Hmmm...this is interesting.

      Elliott, if I understand what you are saying, it's
      really up to the Xforms community to support FO format
      semantics. So instead of having an FO processor output
      Xforms, they would compile an XForm with embedded FO
      semantics with which to decorate it...like what
      OpenOffice does with embedded FO attributes in ODF.

      Elliott, do you think that it will be feasible to
      implement an FO processor to render XForms as well as
      support XForms functionality perhaps by implementing
      FO objects for interactive renderings? I know that
      several companies including IBM and Corel are
      implementing XForms using SVG. I don't know if any
      effort is being contemplated for FO.

      Thanks,
      peter


      --- Eliot Kimber <ekimber@...> wrote:

      > Peter Wu wrote:
      > > Greetings,
      > >
      > > XSL-FO can output HTML but not XForms.
      >
      > I think you must mean FOP not XSL-FO. XSL-FO is just
      > the standard and
      > says nothing about specific renderered results.
      >
      > > Unfortunately, FO doesn't speak XForms at least
      > not
      > > beyond format semantics. It is therefore unlikely
      > that
      > > an Xform output adapter will ever be created for
      > FO
      > > unless the specification is extended to explicitly
      > > cover XForms which for now lies beyond its
      > charter.
      >
      > I think you're misunderstanding both what XSL-FO is
      > and isn't for and
      > how it has been designed to work with other
      > specifications.
      >
      > XForms forms could be integrated with larger FO
      > documents using
      > instream-foreign object, just as you can include SVG
      > graphics. There's
      > nothing about the FO spec that prevents it or that
      > needs to explicitly
      > allow it. It would still be up to specific FO
      > processors to do something
      > sensible with the result.
      >
      > XSL-FO does include some (largely unimplemented)
      > formatting objects for
      > interactive renderings (multi-switch, etc.).
      >
      > It's possible that there could be a tighter
      > integration of XForms with
      > FO in the sense that the various XForms elements
      > could be mapped to
      > formatting objects with their FO-processing-context
      > semantics defined
      > (that is, what the area tree implications of a given
      > form component
      > are). But I think that activity would be more
      > appropriately driven by
      > the XForms community, if it's needed at all.
      >
      > Remember that W3C specifications are driven largely
      > by implementation
      > which is in turn driven largely by what tool
      > developers do in response
      > to customer requirements.
      >
      > Therefore, if an FO implementation starts doing
      > interesting things with
      > XForms integration beyond simply allowing forms to
      > be embedded in FO
      > instances then something might happen in the specs.
      > Until that time it
      > is a certainty that nothing will happen.
      >
      > Cheers,
      >
      > Eliot
      > --
      > W. Eliot Kimber
      > Professional Services
      > Innodata Isogen
      > 9390 Research Blvd, #410
      > Austin, TX 78759
      > (512) 372-8841
      >
      > ekimber@...
      > www.innodata-isogen.com
      >
      >
    • Peter Wu
      Greetings, In regards to John s point, ...isn t that what open standards are for - to allow people to offload those tasks in an easy way from their app to
      Message 2 of 19 , Oct 20, 2005
      • 0 Attachment
        Greetings,

        In regards to John's point, "...isn't that what open
        standards are for - to allow people to offload those
        tasks in an easy way from their app to other, more
        specialized apps? Sure it is", I whole-heartedly
        agree. I appologize for my rather limited thinking.
        Just because the XSL-FO spec doesn't speak directly to
        XForms doesn't mean that Xforms can not potentially be
        used to implement Xforms using features that have
        already been incorporated in the specification like
        what Elliott mentioned, namely instream-foreign object
        and objects for interactive renderings.

        Like John said, Microsoft, Adobe and others have
        already implemented the active documents. I don't know
        in fact if Xforms as supported by OpenOffice
        incorporates FO semantics for formatting purposes but
        the typical OpenOffice word processing document does
        and I imagine that Xforms processors can be developed
        to translate the FO instructions or make use of them
        in the same way.

        Thanks,
        peter






        --- John Madden <john.madden@...> wrote:

        > Peter/Eliot/others,
        >
        > Thanks for the info, particularly the perspective on
        > XSL-FO (which I'll just
        > call XSL) + XForms.
        >
        > Re: Eliot's point about XForms eliciting specific
        > changes in the XSL
        > standard only when-and-if implementers demand it ---
        > That's a fair point.
        >
        > But, evidently Adobe, Microsoft, etc. have
        > recognized an important niche for
        > "active" documents that have reproducible
        > cross-platform appearance (well,
        > Adobe anyway). Thus .pdf has its own whole
        > specifications suite of
        > interactive features (annotations, forms controls,
        > events, etc.) that apply
        > to screen-rendered pdf.
        >
        > As I slowly begin to learn more about XSL, I wonder
        > a little bit about
        > whether a focus on printed output is a little bit
        > odd in today's world. For
        > example, is there an XSL rendering engine today that
        > outputs display
        > postscript? Is there an XSL rendering engine today
        > that outputs pdf with the
        > interactive features accurately rendered when the
        > pdf file is displayed in
        > an Adobe Reader browser window?
        >
        > You could say, well just have your (let's say) web
        > app take responsibility
        > that its XHTML screen output matches your printed
        > output. But on the other
        > hand (and I'm being provocative here), isn't that
        > what open standards are
        > for - to allow people to offload those tasks in an
        > easy way from their app
        > to other, more specialized apps? Sure it is.
        >
        > John
        >
        >
        >
      • Peter Wu
        Greetings, You know what? I think that I might be wrong about XForms incorporating format semantics. I just created one using OpenOffice that contain several
        Message 3 of 19 , Oct 20, 2005
        • 0 Attachment
          Greetings,

          You know what? I think that I might be wrong about
          XForms incorporating format semantics. I just created
          one using OpenOffice that contain several input
          fields. I noticed by looking at content.xml that the
          XForm and input objects defined within it do not
          specify how they are rendered at all. That information
          is specified as embedded ODF (Open Document Format)
          instructions (that include FO and SVG type
          instructions) that are inserted and processed
          separately by OpenOffice as the XForm container
          application.

          This implies that John's EMRs, once transformed into
          ODF can be instantiated with a consistent look and
          feel by any ODF compliant XForm client on any
          platform.

          Thanks,
          peter


          --- Peter Wu <peterlwu@...> wrote:

          > Greetings,
          >
          > In regards to John's point, "...isn't that what open
          > standards are for - to allow people to offload those
          > tasks in an easy way from their app to other, more
          > specialized apps? Sure it is", I whole-heartedly
          > agree. I appologize for my rather limited thinking.
          > Just because the XSL-FO spec doesn't speak directly
          > to
          > XForms doesn't mean that Xforms can not potentially
          > be
          > used to implement Xforms using features that have
          > already been incorporated in the specification like
          > what Elliott mentioned, namely instream-foreign
          > object
          > and objects for interactive renderings.
          >
          > Like John said, Microsoft, Adobe and others have
          > already implemented the active documents. I don't
          > know
          > in fact if Xforms as supported by OpenOffice
          > incorporates FO semantics for formatting purposes
          > but
          > the typical OpenOffice word processing document does
          > and I imagine that Xforms processors can be
          > developed
          > to translate the FO instructions or make use of them
          > in the same way.
          >
          > Thanks,
          > peter
          >
          >
          >
          >
          >
          >
          > --- John Madden <john.madden@...> wrote:
          >
          > > Peter/Eliot/others,
          > >
          > > Thanks for the info, particularly the perspective
          > on
          > > XSL-FO (which I'll just
          > > call XSL) + XForms.
          > >
          > > Re: Eliot's point about XForms eliciting specific
          > > changes in the XSL
          > > standard only when-and-if implementers demand it
          > ---
          > > That's a fair point.
          > >
          > > But, evidently Adobe, Microsoft, etc. have
          > > recognized an important niche for
          > > "active" documents that have reproducible
          > > cross-platform appearance (well,
          > > Adobe anyway). Thus .pdf has its own whole
          > > specifications suite of
          > > interactive features (annotations, forms controls,
          > > events, etc.) that apply
          > > to screen-rendered pdf.
          > >
          > > As I slowly begin to learn more about XSL, I
          > wonder
          > > a little bit about
          > > whether a focus on printed output is a little bit
          > > odd in today's world. For
          > > example, is there an XSL rendering engine today
          > that
          > > outputs display
          > > postscript? Is there an XSL rendering engine today
          > > that outputs pdf with the
          > > interactive features accurately rendered when the
          > > pdf file is displayed in
          > > an Adobe Reader browser window?
          > >
          > > You could say, well just have your (let's say) web
          > > app take responsibility
          > > that its XHTML screen output matches your printed
          > > output. But on the other
          > > hand (and I'm being provocative here), isn't that
          > > what open standards are
          > > for - to allow people to offload those tasks in an
          > > easy way from their app
          > > to other, more specialized apps? Sure it is.
          > >
          > > John
          > >
          > >
          > >
          >
          >
        • John Madden
          Hey Peter, This may be just what I am looking for. I know only a very little about ODF as of right now, but it s one of the standards I promised myself I would
          Message 4 of 19 , Oct 20, 2005
          • 0 Attachment
            Hey Peter,

            This may be just what I am looking for. I know only a very little about ODF
            as of right now, but it's one of the standards I promised myself I would
            look at. Actually, I think I might like it because it's OASIS, and I'm a
            Relax NG/DSDL fanatic. So maybe I should look at it closely.

            I do wish I could look to XSL (aka XSL-FO) itself for this, because I'd like
            a W3C standard. But (and Eliot, here's my point) people who are looking for
            cross platform presentation standards these days are going to almost
            inevitably demand an easy route to incorporate active features. I'm only
            just now trying to grasp how XSL inline formatting objects would work for
            this, and maybe it will turn out that XSL is just as good a target as ODF.

            In fact, I'd love that, because really I am not looking for a "final"
            presentation format, but rather for a presentation-format-aware adapter
            format that could serve as an intermediate target for my data-oriented XML,
            and could be processed into a variety of end-formats.

            On a related topic (and again cut me some slack, because I'm a complete XSL
            newbie), I've found it kind of odd that I've not come across many
            discussions of XSL processors that target XHTML as *output* (some
            discussions talk about using HTML/XHTML as input for transformation to XSL).
            In my application, I'm trying to get my data-oriented XML into a variety of
            presentation formats including both workstation displays and print. Do any
            XSL processors out there emit XHTML as output?

            John


            _____

            From: XSL-FO@yahoogroups.com [mailto:XSL-FO@yahoogroups.com] On Behalf Of
            Peter Wu
            Sent: Thursday, October 20, 2005 4:02 PM
            To: XSL-FO@yahoogroups.com
            Subject: RE: [XSL-FO] XSL-FO


            Greetings,

            You know what? I think that I might be wrong about
            XForms incorporating format semantics. I just created
            one using OpenOffice that contain several input
            fields. I noticed by looking at content.xml that the
            XForm and input objects defined within it do not
            specify how they are rendered at all. That information
            is specified as embedded ODF (Open Document Format)
            instructions (that include FO and SVG type
            instructions) that are inserted and processed
            separately by OpenOffice as the XForm container
            application.

            This implies that John's EMRs, once transformed into
            ODF can be instantiated with a consistent look and
            feel by any ODF compliant XForm client on any
            platform.

            Thanks,
            peter


            --- Peter Wu <peterlwu@...> wrote:

            > Greetings,
            >
            > In regards to John's point, "...isn't that what open
            > standards are for - to allow people to offload those
            > tasks in an easy way from their app to other, more
            > specialized apps? Sure it is", I whole-heartedly
            > agree. I appologize for my rather limited thinking.
            > Just because the XSL-FO spec doesn't speak directly
            > to
            > XForms doesn't mean that Xforms can not potentially
            > be
            > used to implement Xforms using features that have
            > already been incorporated in the specification like
            > what Elliott mentioned, namely instream-foreign
            > object
            > and objects for interactive renderings.
            >
            > Like John said, Microsoft, Adobe and others have
            > already implemented the active documents. I don't
            > know
            > in fact if Xforms as supported by OpenOffice
            > incorporates FO semantics for formatting purposes
            > but
            > the typical OpenOffice word processing document does
            > and I imagine that Xforms processors can be
            > developed
            > to translate the FO instructions or make use of them
            > in the same way.
            >
            > Thanks,
            > peter
            >
            >
            >
            >
            >
            >
            > --- John Madden <john.madden@...> wrote:
            >
            > > Peter/Eliot/others,
            > >
            > > Thanks for the info, particularly the perspective
            > on
            > > XSL-FO (which I'll just
            > > call XSL) + XForms.
            > >
            > > Re: Eliot's point about XForms eliciting specific
            > > changes in the XSL
            > > standard only when-and-if implementers demand it
            > ---
            > > That's a fair point.
            > >
            > > But, evidently Adobe, Microsoft, etc. have
            > > recognized an important niche for
            > > "active" documents that have reproducible
            > > cross-platform appearance (well,
            > > Adobe anyway). Thus .pdf has its own whole
            > > specifications suite of
            > > interactive features (annotations, forms controls,
            > > events, etc.) that apply
            > > to screen-rendered pdf.
            > >
            > > As I slowly begin to learn more about XSL, I
            > wonder
            > > a little bit about
            > > whether a focus on printed output is a little bit
            > > odd in today's world. For
            > > example, is there an XSL rendering engine today
            > that
            > > outputs display
            > > postscript? Is there an XSL rendering engine today
            > > that outputs pdf with the
            > > interactive features accurately rendered when the
            > > pdf file is displayed in
            > > an Adobe Reader browser window?
            > >
            > > You could say, well just have your (let's say) web
            > > app take responsibility
            > > that its XHTML screen output matches your printed
            > > output. But on the other
            > > hand (and I'm being provocative here), isn't that
            > > what open standards are
            > > for - to allow people to offload those tasks in an
            > > easy way from their app
            > > to other, more specialized apps? Sure it is.
            > >
            > > John
            > >
            > >
            > >
            >
            >




            SPONSORED LINKS
            Xml
            <http://groups.yahoo.com/gads?t=ms&k=Xml+xsl&w1=Xml+xsl&w2=Xsl&w3=Xsl-fo&c=3
            &s=34&.sig=qJNw325nPUVJp-j4hI-Zmg> xsl Xsl
            <http://groups.yahoo.com/gads?t=ms&k=Xsl&w1=Xml+xsl&w2=Xsl&w3=Xsl-fo&c=3&s=3
            4&.sig=9XiQq_Vj008M0D4X7cwELA> Xsl-fo
            <http://groups.yahoo.com/gads?t=ms&k=Xsl-fo&w1=Xml+xsl&w2=Xsl&w3=Xsl-fo&c=3&
            s=34&.sig=8RNnbDshkhY26gg0VNw76Q>

            _____

            YAHOO! GROUPS LINKS



            * Visit your group "XSL-FO <http://groups.yahoo.com/group/XSL-FO> "
            on the web.


            * To unsubscribe from this group, send an email to:
            XSL-FO-unsubscribe@yahoogroups.com
            <mailto:XSL-FO-unsubscribe@yahoogroups.com?subject=Unsubscribe>


            * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
            <http://docs.yahoo.com/info/terms/> .


            _____




            [Non-text portions of this message have been removed]
          • Peter Wu
            Hi John, I don t know if there are any interactive display technologies in existence today that are based entirely on XSL (please help John by correcting me on
            Message 5 of 19 , Oct 20, 2005
            • 0 Attachment
              Hi John,

              I don't know if there are any interactive display
              technologies in existence today that are based
              entirely on XSL (please help John by correcting me on
              this if I'm wrong).

              Of course you can transform your EMR data using XSL so
              that it can be displayed in a variety of output
              formats (HTML, XHTML, SVG, XSL-FO) but I think that
              you may already know that. On the other hand, if
              that's what you need, you might want to look at this
              on-line demo for this product called Stylus:
              http://www.stylusstudio.com/videos/tutorial1/tutorial1.html.

              However, I think what you're really asking for is a
              way to translate EMR's into a portable display and
              editing format, preferably XSL-based. This one's kind
              of tough. Eliot, do you have any ideas?

              The problem with HTML, of course, is that it's not
              well formed so that your forms can be parsed. Of
              course, you can solve this particular problem by
              switching over to XHTML. However, your solution may
              very well lie in the world of XForms at least as an
              SVG implementation. I think that only XForms provide
              both interactive read and write capability.

              I don't know how far IBM and Corel has progressed in
              developing this technology
              (http://www-128.ibm.com/developerworks/library/x-svgxf2/).
              Supposedly, by having your customer download an
              SVG/XForms browser plug-in, they would be able to
              retrieve their EMR, read it and update it using
              web-services or other means. On the other hand, why
              install an SVG plug-in when you download a browser
              that displays (and I presume, updates) XForms, SVG,
              XSL-FO and XHTML all at the same time
              (http://www.xsmiles.org/).

              Thanks,
              peter



              --- John Madden <john.madden@...> wrote:

              > Hey Peter,
              >
              > This may be just what I am looking for. I know only
              > a very little about ODF
              > as of right now, but it's one of the standards I
              > promised myself I would
              > look at. Actually, I think I might like it because
              > it's OASIS, and I'm a
              > Relax NG/DSDL fanatic. So maybe I should look at it
              > closely.
              >
              > I do wish I could look to XSL (aka XSL-FO) itself
              > for this, because I'd like
              > a W3C standard. But (and Eliot, here's my point)
              > people who are looking for
              > cross platform presentation standards these days are
              > going to almost
              > inevitably demand an easy route to incorporate
              > active features. I'm only
              > just now trying to grasp how XSL inline formatting
              > objects would work for
              > this, and maybe it will turn out that XSL is just as
              > good a target as ODF.
              >
              > In fact, I'd love that, because really I am not
              > looking for a "final"
              > presentation format, but rather for a
              > presentation-format-aware adapter
              > format that could serve as an intermediate target
              > for my data-oriented XML,
              > and could be processed into a variety of
              > end-formats.
              >
              > On a related topic (and again cut me some slack,
              > because I'm a complete XSL
              > newbie), I've found it kind of odd that I've not
              > come across many
              > discussions of XSL processors that target XHTML as
              > *output* (some
              > discussions talk about using HTML/XHTML as input for
              > transformation to XSL).
              > In my application, I'm trying to get my
              > data-oriented XML into a variety of
              > presentation formats including both workstation
              > displays and print. Do any
              > XSL processors out there emit XHTML as output?
              >
              > John
              >
              >
              > _____
              >
              > From: XSL-FO@yahoogroups.com
              > [mailto:XSL-FO@yahoogroups.com] On Behalf Of
              > Peter Wu
              > Sent: Thursday, October 20, 2005 4:02 PM
              > To: XSL-FO@yahoogroups.com
              > Subject: RE: [XSL-FO] XSL-FO
              >
              >
              > Greetings,
              >
              > You know what? I think that I might be wrong about
              > XForms incorporating format semantics. I just
              > created
              > one using OpenOffice that contain several input
              > fields. I noticed by looking at content.xml that the
              > XForm and input objects defined within it do not
              > specify how they are rendered at all. That
              > information
              > is specified as embedded ODF (Open Document Format)
              > instructions (that include FO and SVG type
              > instructions) that are inserted and processed
              > separately by OpenOffice as the XForm container
              > application.
              >
              > This implies that John's EMRs, once transformed into
              > ODF can be instantiated with a consistent look and
              > feel by any ODF compliant XForm client on any
              > platform.
              >
              > Thanks,
              > peter
              >
              >
              > --- Peter Wu <peterlwu@...> wrote:
              >
              > > Greetings,
              > >
              > > In regards to John's point, "...isn't that what
              > open
              > > standards are for - to allow people to offload
              > those
              > > tasks in an easy way from their app to other, more
              > > specialized apps? Sure it is", I whole-heartedly
              > > agree. I appologize for my rather limited
              > thinking.
              > > Just because the XSL-FO spec doesn't speak
              > directly
              > > to
              > > XForms doesn't mean that Xforms can not
              > potentially
              > > be
              > > used to implement Xforms using features that have
              > > already been incorporated in the specification
              > like
              > > what Elliott mentioned, namely instream-foreign
              > > object
              > > and objects for interactive renderings.
              > >
              > > Like John said, Microsoft, Adobe and others have
              > > already implemented the active documents. I don't
              > > know
              > > in fact if Xforms as supported by OpenOffice
              > > incorporates FO semantics for formatting purposes
              > > but
              > > the typical OpenOffice word processing document
              > does
              > > and I imagine that Xforms processors can be
              > > developed
              > > to translate the FO instructions or make use of
              > them
              > > in the same way.
              > >
              > > Thanks,
              > > peter
              > >
              > >
              > >
              > >
              > >
              > >
              > > --- John Madden <john.madden@...> wrote:
              > >
              > > > Peter/Eliot/others,
              > > >
              > > > Thanks for the info, particularly the
              > perspective
              > > on
              > > > XSL-FO (which I'll just
              > > > call XSL) + XForms.
              > > >
              > > > Re: Eliot's point about XForms eliciting
              > specific
              > > > changes in the XSL
              > > > standard only when-and-if implementers demand it
              > > ---
              > > > That's a fair point.
              > > >
              > > > But, evidently Adobe, Microsoft, etc. have
              > > > recognized an important niche for
              > > > "active" documents that have reproducible
              > > > cross-platform appearance (well,
              > > > Adobe anyway). Thus .pdf has its own whole
              > > > specifications suite of
              > > > interactive features (annotations, forms
              > controls,
              > > > events, etc.) that apply
              > > > to screen-rendered pdf.
              > > >
              > > > As I slowly begin to learn more about XSL, I
              > > wonder
              > > > a little bit about
              > > > whether a focus on printed output is a little
              > bit
              > > > odd in today's world. For
              > > > example, is there an XSL rendering engine today
              > > that
              > > > outputs display
              > > > postscript? Is there an XSL rendering engine
              > today
              > > > that outputs pdf with the
              > > > interactive features accurately rendered when
              > the
              > > > pdf file is displayed in
              > > > an Adobe Reader browser window?
              > > >
              > > > You could say, well just have your (let's say)
              > web
              > > > app take responsibility
              > > > that its XHTML screen output matches your
              > printed
              > > > output. But on the other
              > > > hand (and I'm being provocative here), isn't
              > that
              > > > what open standards are
              > > > for - to allow people to offload those tasks in
              > an
              > > > easy way from their app
              > > > to other, more specialized apps? Sure it is.
              > > >
              > > > John
              > > >
              > > >
              > > >
              > >
              > >
              >
              >
              >
              >
              >
              === message truncated ===
            • Eliot Kimber
              ... XSL-FO is explicitly about generating *paginated* output. Therefore it wouldn t make sense to generate XHTML as the output of an XSL-FO processor. As
              Message 6 of 19 , Oct 20, 2005
              • 0 Attachment
                John Madden wrote:

                > On a related topic (and again cut me some slack, because I'm a complete XSL
                > newbie), I've found it kind of odd that I've not come across many
                > discussions of XSL processors that target XHTML as *output* (some
                > discussions talk about using HTML/XHTML as input for transformation to XSL).
                > In my application, I'm trying to get my data-oriented XML into a variety of
                > presentation formats including both workstation displays and print. Do any
                > XSL processors out there emit XHTML as output?

                XSL-FO is explicitly about generating *paginated* output. Therefore it
                wouldn't make sense to generate XHTML as the output of an XSL-FO processor.

                As others have pointed out, that's what XSLT is for.

                Cheers,

                Eliot
                --
                W. Eliot Kimber
                Professional Services
                Innodata Isogen
                9390 Research Blvd, #410
                Austin, TX 78759
                (512) 372-8841

                ekimber@...
                www.innodata-isogen.com
              • John Madden
                Peter/Eliot, ... Yeah, kind of. Actually, I m involved more in EMR standards development than in EMR implementation, and what I m really looking for is not a
                Message 7 of 19 , Oct 20, 2005
                • 0 Attachment
                  Peter/Eliot,

                  > However, I think what you're really asking for is a
                  > way to translate EMR's into a portable display and
                  > editing format, preferably XSL-based.

                  Yeah, kind of. Actually, I'm involved more in EMR standards development than
                  in EMR implementation, and what I'm really looking for is not a solution for
                  any particular implementation of EMR, but rather an XML target format that
                  could serve as a framework component that would:

                  (a) be pretty close to the presentation layer, but not quite there;
                  (b) hence easily interconvertible by end-implementers into whatever "actual"
                  display format they wanted (html, xhtml, doc, pdf, rtf, OpenDocument, txt,
                  whatever);
                  (c) would yield consistent output;
                  AND
                  (d) would have a concept of active features when converted to an onscreen
                  presentation view.

                  Not much to ask, eh? (Forget which popular song had the line: "I don't want
                  much, just give me the world.")

                  I kind of (sigh) think the closest thing to this is pdf itself. It prints,
                  it displays onscreen, it displays on handheld devices, and it supports
                  onscreen interaction. But the pdf specification is so arcane (and not
                  entirely XML-based, not to mention proprietary), that it isn't a target
                  format that most implementers would consider a great framework component.
                  That's what's nice about XSL.

                  But XSL (like Eliot says) is committed to things like pagination, etc., that
                  is it doesn't have a native model of paper-CRT equivalence. I guess the idea
                  of a paper page is almost impossible to translate accurately to a screen.

                  PDF gets around this by making pdf's appear paginated even when they are
                  being displayed inside a reader window in a browser, but I'll be first to
                  admit it yields a stilted experience for the user. Ever go crazy trying to
                  read a pdf document in a browser window? It drives me nuts, and I almost
                  always end up printing the darn thing out and reading the paper version
                  instead.

                  > The problem with HTML, of course, is that it's not
                  > well formed so that your forms can be parsed. Of
                  > course, you can solve this particular problem by
                  > switching over to XHTML.

                  Yeah, I think the real problem even with XHTML is the browser-to-browser
                  variations in appearance.

                  Anyway, its great of both of you to share your wisdom on this. I think I
                  will focus on learning XSL-FO for now and hope that by the time I get good
                  at it, somebody else will have figured this all out!!

                  John
                • Peter Wu
                  Hi John, Don t mean to take up more of your time but just out of curiosity, are you using or planning to use HL7 to encode your EMRs and is HL7 what your
                  Message 8 of 19 , Oct 20, 2005
                  • 0 Attachment
                    Hi John,

                    Don't mean to take up more of your time but just out
                    of curiosity, are you using or planning to use HL7 to
                    encode your EMRs and is HL7 what your transforming
                    into XSL-FO?

                    Thanks,
                    peter

                    --- John Madden <john.madden@...> wrote:

                    > Peter/Eliot,
                    >
                    > > However, I think what you're really asking for is
                    > a
                    > > way to translate EMR's into a portable display and
                    > > editing format, preferably XSL-based.
                    >
                    > Yeah, kind of. Actually, I'm involved more in EMR
                    > standards development than
                    > in EMR implementation, and what I'm really looking
                    > for is not a solution for
                    > any particular implementation of EMR, but rather an
                    > XML target format that
                    > could serve as a framework component that would:
                    >
                    > (a) be pretty close to the presentation layer, but
                    > not quite there;
                    > (b) hence easily interconvertible by
                    > end-implementers into whatever "actual"
                    > display format they wanted (html, xhtml, doc, pdf,
                    > rtf, OpenDocument, txt,
                    > whatever);
                    > (c) would yield consistent output;
                    > AND
                    > (d) would have a concept of active features when
                    > converted to an onscreen
                    > presentation view.
                    >
                    > Not much to ask, eh? (Forget which popular song had
                    > the line: "I don't want
                    > much, just give me the world.")
                    >
                    > I kind of (sigh) think the closest thing to this is
                    > pdf itself. It prints,
                    > it displays onscreen, it displays on handheld
                    > devices, and it supports
                    > onscreen interaction. But the pdf specification is
                    > so arcane (and not
                    > entirely XML-based, not to mention proprietary),
                    > that it isn't a target
                    > format that most implementers would consider a great
                    > framework component.
                    > That's what's nice about XSL.
                    >
                    > But XSL (like Eliot says) is committed to things
                    > like pagination, etc., that
                    > is it doesn't have a native model of paper-CRT
                    > equivalence. I guess the idea
                    > of a paper page is almost impossible to translate
                    > accurately to a screen.
                    >
                    > PDF gets around this by making pdf's appear
                    > paginated even when they are
                    > being displayed inside a reader window in a browser,
                    > but I'll be first to
                    > admit it yields a stilted experience for the user.
                    > Ever go crazy trying to
                    > read a pdf document in a browser window? It drives
                    > me nuts, and I almost
                    > always end up printing the darn thing out and
                    > reading the paper version
                    > instead.
                    >
                    > > The problem with HTML, of course, is that it's not
                    > > well formed so that your forms can be parsed. Of
                    > > course, you can solve this particular problem by
                    > > switching over to XHTML.
                    >
                    > Yeah, I think the real problem even with XHTML is
                    > the browser-to-browser
                    > variations in appearance.
                    >
                    > Anyway, its great of both of you to share your
                    > wisdom on this. I think I
                    > will focus on learning XSL-FO for now and hope that
                    > by the time I get good
                    > at it, somebody else will have figured this all
                    > out!!
                    >
                    > John
                    >
                    >
                    >
                  • Dave Pawson
                    ... It might be better understood (or at least explicit) if you continued to use XSL-FO John? XSL is still interpreted by some as meaning XSLT, the transform
                    Message 9 of 19 , Oct 21, 2005
                    • 0 Attachment
                      On Thu, 2005-10-20 at 12:39 -0400, John Madden wrote:
                      > Peter/Eliot/others,
                      >
                      > Thanks for the info, particularly the perspective on XSL-FO (which I'll just
                      > call XSL)

                      It might be better understood (or at least explicit) if you continued
                      to use XSL-FO John?


                      XSL is still interpreted by some as meaning XSLT, the transform
                      language.

                      It was a single entity, split into XSL and XSLT
                      and was messy for a while. The use of XSL-FO
                      seems to keep it clear in most circles.

                      HTH
                      --
                      Regards,

                      Dave Pawson
                      XSLT + Docbook FAQ
                      http://www.dpawson.co.uk
                    • John Madden
                      Dave, I ll do that from now on. And btw, I m using your excellent book to learn it! Thanks. John ________________________________ From: XSL-FO@yahoogroups.com
                      Message 10 of 19 , Oct 21, 2005
                      • 0 Attachment
                        Dave,

                        I'll do that from now on. And btw, I'm using your excellent book to learn
                        it!
                        Thanks.

                        John


                        ________________________________

                        From: XSL-FO@yahoogroups.com [mailto:XSL-FO@yahoogroups.com] On
                        Behalf Of Dave Pawson
                        Sent: Friday, October 21, 2005 1:42 PM
                        To: XSL-FO@yahoogroups.com
                        Subject: RE: [XSL-FO] XSL-FO


                        On Thu, 2005-10-20 at 12:39 -0400, John Madden wrote:
                        > Peter/Eliot/others,
                        >
                        > Thanks for the info, particularly the perspective on XSL-FO (which
                        I'll just
                        > call XSL)

                        It might be better understood (or at least explicit) if you
                        continued
                        to use XSL-FO John?


                        XSL is still interpreted by some as meaning XSLT, the transform
                        language.

                        It was a single entity, split into XSL and XSLT
                        and was messy for a while. The use of XSL-FO
                        seems to keep it clear in most circles.

                        HTH
                        --
                        Regards,

                        Dave Pawson
                        XSLT + Docbook FAQ
                        http://www.dpawson.co.uk



                        ________________________________

                        YAHOO! GROUPS LINKS


                        * Visit your group "XSL-FO
                        <http://groups.yahoo.com/group/XSL-FO> " on the web.

                        * To unsubscribe from this group, send an email to:
                        XSL-FO-unsubscribe@yahoogroups.com
                        <mailto:XSL-FO-unsubscribe@yahoogroups.com?subject=Unsubscribe>

                        * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                        Service <http://docs.yahoo.com/info/terms/> .


                        ________________________________
                      • Peter Wu
                        I m getting quite an education. Thanks Dave!
                        Message 11 of 19 , Oct 21, 2005
                        • 0 Attachment
                          I'm getting quite an education.

                          Thanks Dave!


                          --- Dave Pawson <DaveP@...> wrote:

                          > On Thu, 2005-10-20 at 12:39 -0400, John Madden
                          > wrote:
                          > > Peter/Eliot/others,
                          > >
                          > > Thanks for the info, particularly the perspective
                          > on XSL-FO (which I'll just
                          > > call XSL)
                          >
                          > It might be better understood (or at least explicit)
                          > if you continued
                          > to use XSL-FO John?
                          >
                          >
                          > XSL is still interpreted by some as meaning XSLT,
                          > the transform
                          > language.
                          >
                          > It was a single entity, split into XSL and XSLT
                          > and was messy for a while. The use of XSL-FO
                          > seems to keep it clear in most circles.
                          >
                          > HTH
                          > --
                          > Regards,
                          >
                          > Dave Pawson
                          > XSLT + Docbook FAQ
                          > http://www.dpawson.co.uk
                          >
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.