home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!gossip.pyramid.com!pyramid!infmx!hartman
- From: hartman@informix.com (Robert Hartman)
- Newsgroups: comp.text.sgml
- Subject: Re: FrameBuilder
- Message-ID: <1993Jan12.202201.23614@informix.com>
- Date: 12 Jan 93 20:22:01 GMT
- References: <1993Jan12.131750.28407@iscnvx.lmsc.lockheed.com> <1993Jan12.150838.22518@gmd.de>
- Sender: news@informix.com (Usenet News)
- Organization: Informix Software, Inc.
- Lines: 21
-
- In article <1993Jan12.150838.22518@gmd.de> thomas@gmd.de writes:
- >In article 28407@iscnvx.lmsc.lockheed.com, lange@iscnvx.lmsc.lockheed.com (Alex Lange) writes:
- >>
- >> As for "native SGML support," I realized that was an untruth when I was
- >> told that documents are stored in Frame's binary format.
- >
- >Although I too would prefer that SGML editors store documents in SGML,
- >rather than some binary format, this is not uncommon. Well, at least
- >SoftQuad's Author/Editor product also does this. I don't think this
- >should be one of the required features for a "fully conform" SGML editor.
-
- I do. The entire point of SGML is to provide generalized
- application-level access to a document's contents. This can only be
- done if the documents are stored in marked-up ASCII form. Any binary
- format will by nature be propietary to some degree. This will prevent
- other applications from importing or operating on that text (important
- keyword that). While I might go so far as to say that one could
- "precompile" or store style catalogs in a binary format, that's as far
- as the SGML concept can be stretched without breaking.
-
- -r
-