home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / text / sgml / 1273 < prev    next >
Encoding:
Text File  |  1993-01-08  |  1.7 KB  |  39 lines
  1. Newsgroups: comp.text.sgml
  2. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!linus!linus.mitre.org!thelonius!john
  3. From: john@thelonius.mitre.org (John D. Burger)
  4. Subject: Separation of text and markup
  5. Message-ID: <1993Jan8.194217.9341@linus.mitre.org>
  6. Sender: john@thelonius (John D. Burger)
  7. Nntp-Posting-Host: thelonius.mitre.org
  8. Organization: Artificial Intelligence Center, MITRE Corporation
  9. References: <C0BsDK.5G2@undergrad.math.waterloo.edu> <19930105.004@erik.naggum.no>
  10. Date: Fri, 8 Jan 1993 19:42:17 GMT
  11. Lines: 26
  12.  
  13. Erik Naggum (erik@naggum.no) writes:
  14.  
  15.   If you wish to separate the markup from the text completely, you will need to
  16.   establish a means to identify the start and end of all elements in the
  17.   separated text.  This is certainly _possible_, but you wouldn't want to do it,
  18.   because you would end up with more things to take care of than writing an
  19.   SGML-aware editor from scratch.
  20.  
  21. We're developing a text understanding system that marks up the source with
  22. semantic information in SGML (e.g. <VIOLENCE victim="...">).  What we will
  23. eventually have is a SUITE of such processors, from simple (but fast) to
  24. sophisticated (but slow).  Different users may run different processors on the
  25. same source document, and may eventually wish to merge or compare the results.
  26.  
  27. What this seems to require is exactly what you describe, namely, keeping track of
  28. where every element (or at least every tag) is, in terms of the original
  29. document.
  30.  
  31. Since processors might treat white space differently (e.g. two blank lines vs.
  32. indentation for paragraphs), it even seems that we have to index the SGML down to
  33. the individual characters, not just words or other tokens.
  34.  
  35. Are there any tools we can take advantage of that already do this?
  36.  
  37. John Burger
  38. john@mitre.org
  39.