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

RE: [xml-doc] Migrating From FrameMaker to XML Publishing?

Expand Messages
  • kadlec
    Hi, Jim - That s what s happening with XML solutions. Tools drive the adoption of XML, because the best old solutions -- Interleaf (Quicksilver) and Frame
    Message 1 of 17 , Feb 29, 2004
      Hi, Jim -

      "That's what's happening with XML "solutions." Tools drive the
      of XML, because the best old solutions -- Interleaf
      (Quicksilver) and
      Frame -- are no longer adequate."

      I'm not sure I agree with your core premise here- I think the internet
      drove the subset to XML, not inadequate tools. What is driving XML tools
      is the internet because the internet needed a better subset than HTML
      and ways to manipulate text... sans browser tools. Tools don't drive
      anything... the work drives the creation of the tools. The need to do
      electronic interchange of text as well as data is what drove the need to
      develop the internet.

      The evolution is still on-going with Adobe - Adobe was never good at
      marketing for technical/corporate business... they haven't improved
      their approach much since they purchased FrameMaker. But, in my opinion,
      they are still developing brilliant tools. If the Frame tool and its
      marketing doesn't continue to evolve, it will go the way of I-Leaf and
      Ventura... but XML/SGML will continue and those who are developing for
      the markup languages will survive because I don't see the internet going
      away any time soon. I think some of the new tools will be fine for the
      surface-to-air SAX application of porting to the internet... but
      SGML/XML can have deeper roots and purposes in electronic information
      work products.

      Separate from the internet, technical publishing work needs a heavy
      engine, DOM and SAX and/or the combos... there are many on the drawing
      table as we speak and waiting for the economy to recover. Whether Adobe
      retools their Frame development language is their call; this combo
      product between standard Frame and Frame+SGML has some interesting
      aspects. If they don't continue to evolve it, someone will build one
      and we will adapt - not convert, transform. Or maybe Adobe has a phasing
      plan from Frame-to-??? - and those of you who are saying In-Design, be
      careful, there are two distinct markets here and what works for one and
      the other will evolve into something completely different - - I think --
      as those two markets morph on their own - perhaps driven by what
      electronic interchange really needs, instead of being driven by output
      media devices.

      Thanks for your input. Maybe you could clarify further?

      Sharon Kadlec
      17715 Eureka Avenue West
      Farmington, MN 55024-9088

      -----Original Message-----
      From: Jim Strohm [mailto:jstrohm@...]
      Sent: Saturday, February 28, 2004 3:54 AM
      To: xml-doc@yahoogroups.com
      Subject: Re: [xml-doc] Migrating From FrameMaker to XML Publishing?

      The savvy shops that still use Frame for large projects already know
      that Frame is imperfect and incomplete, and they actively seek out the
      same kinds of tools that the *nix shops either found or developed to
      expand their roff-based solutions into something that worked. (My most
      meaningful experience stems from what JC Penney was doing in the
      mid-90s to produce their catalogs.)

      As far as Frame goes -- I'm convinced that Adobe could be doing quite a
      bit more to promote third-party plug-ins and to more fully document the
      stuff that's already in Frame. Merely providing accessible and
      COMPLETE documentation on all of Frame's functionality would drive
      sales of another million licenses a year. Purchasing and then giving
      away some of the cool tools in the marketplace today would drive
      another million licenses a year as soon as users saw some of the cool
      stuff you can do with Frame plug-ins.

      And how does that work for the developers?

      Let's say you could automate a process that's a necessary nuisance in
      Frame, like generating a list of all the cross-references in a Frame
      document. I could do this by hand, at an expense of maybe 50 cents a
      crossref (hourly contractor rate). I could develop a tool to do this
      in a few months, assuming starting from scratch, buying the dev tools,
      and debugging -- and then hoping to sell it for $35 a download, without
      any real marketing plan, initiative, or budget. (Three months at $80
      an hour plus tools -- $75K.) Or Adobe could develop the tool
      in-house, or else buy the tool from outside for a fair price -- and
      release it for free to help drive more Frame license sales. (Clue --
      plant a hook in the plug-in that requires updating to the latest
      license version. I worked a gig this year in a shop that still used
      Frame 5.5.7 under Win2K for production.)

      The fact is that savvy users DO pay for tools when the tool saves time,
      or at least saves drudgery. And if there's significant add-in support
      from the prime vendor -- and this would be Adobe -- user loyalty is
      greatly enhanced when "free" stuff comes down the pipeline to drive
      present and future license sales.

      That's what's happening with XML "solutions." Tools drive the adoption
      of XML, because the best old solutions -- Interleaf (Quicksilver) and
      Frame -- are no longer adequate.

      Hey, here's a question -- when was the last time you asked your boss to
      buy a license for the latest version of Microsoft Word because it had
      a compelling new feature that would repay the cost of a new license in
      a few days?

      Hm, I guess that's part of why some folks still stick with klunky ol'
      Frame. Or klunky ol' XML.

      Yahoo! Groups Links
    Your message has been successfully submitted and would be delivered to recipients shortly.