home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!uknet!pavo.csi.cam.ac.uk!ag129
- From: ag129@cus.cam.ac.uk (Alasdair Grant)
- Newsgroups: comp.text.sgml
- Subject: Re: SGML for data querying
- Message-ID: <1993Jan7.180136.236@infodev.cam.ac.uk>
- Date: 7 Jan 93 18:01:36 GMT
- References: <1993Jan7.021616.11906@nuscc.nus.sg> <1993Jan7.142852.23671@infodev.cam.ac.uk> <19930107.090654.710@almaden.ibm.com>
- Sender: news@infodev.cam.ac.uk (USENET news)
- Organization: U of Cambridge, England
- Lines: 16
- Nntp-Posting-Host: bootes.cus.cam.ac.uk
-
- In article <19930107.090654.710@almaden.ibm.com> drmacro@ralvm13.VNET.IBM.COM writes:
- >But it's not that simple. If you define "SGML import and export" as
- >being able to import a document and then immediately export, byte for
- >byte, the original document, then what you are storing in your
- >database is SGML, even if the internal representation is proprietary.
- >Thus you must support SGML features like entity references, SDATA,
- >NDATA, etc., etc. This support can be added to hierarchical,
-
- Thanks for your reply. I just want to pick up on something - what do
- you think about including features like comments, tag minimization,
- and data tagging in a database? If you don't, you aren't really storing
- the "real SGML", but I honestly can't see the point of remembering that
- tag of item X was minimized while tag of item Y wasn't. Seems to me
- that there is at least one level of SGML which gets in the way of
- database applications, and ought to be stripped out in any importation
- of SGML into a database.
-