Re: RS/RE: basic questions

At 10:44 PM 10/2/96 EDT, you wrote:
>You also need the newline to be significant between <emph>these</emph>
><number>two</number> lines.

I don't think so. In fact, I have since thought that I should take out my
newline-becomes-space rule altogether. Most text editors seem to put spaces
at the end of lines before they word-wrap. Touch-typists will put them in
without thinking about it. So under what circumstances are these newlines
between words without spaces going to arise? I think that because we cannot
SEE the spaces at the end of lines, we presume they are not there.

Some editors wrap visually without inserting newlines at all, so those
aren't a problem.

>There's no point in practice in being compatible with 8879 -- instead, XML
>has to be compatible with actual tools.  Probably the most widespread
>tools that read SGML are HoTMetaL, Panorama, Adept, and A/E, with NSGMLS
>and SGMLS and Omnimark being the most widespread on the `next layer down'
>(conceptually, I don't mean to deprecate them!).  I don't list DynaText
>because the viewer is the widespread part, and it reads a compiled form.
>As far as I know, only the tools in the 2nd group I mentioned support
>shortref or datatag or making " a name start character (is that what's
>going on there with <">...</">??).

Well, the shortref is just a syntactic hack to avoid namespace collision. If
we don't want to break tools, we could call the element <PRE>.

>InContext, Microstar's editor (Far and Wide?  I don't mean Near & Far),

Near and Far author.

>SoftQuad Explorer, LivePage, and many many other tools that are perhaps
>less widespread than the ``biggies'' (e.g because newer) also don't, as
>far as I know, support such things.  Correct my privately if I am wrong;
>I will gladly post a summary.  In fact, perhaps this is the sort of
>information that SGML OPEN could mantain??

InContext is based on SGMLS and will support anything SGMLS did.

>At any rate, if most of the most widely deployed SGML tools won't support
>XML because it needs features that they don't implement, the SGML 
>compatibility of XML buys little or nothing, I think.

Agreed.

>Again, if there are any other software writers represented here whose
>current shipping software could not cope with making all whitespace
>significant, and could not supply a script or patch or upgrade or
>sidegrade or whatever within, say, six to twelve months, send me mail
>and I will post a summary early next week.

According to my understanding, the only way to make all whitespace
significant (i.e. to pass all whitespace to the application) is to do that
SGML DECL RE remapping hack. So a LOT of software would have to be changed
(i.e. almost all of the products you mentioned) if you are right that they
do not support SGML DECL tricks.

>On the other hand, let me know if you _could_ cope with this:
>
>* any sequence of whitespace characters is equivalent to a single blank
>* there is no distinction between spaces and newlines
>* an application that processes XML may reduce whitespace to a canonical
>  format, or to an equivalent format, or may leave the whitespace
>  untouched.

Are whitespace characters in element context illegal according to this
scheme? Or are they just passed on to the XML application which must figure
out to discard them? I think that that is still the biggest issue.

If they are illegal, then your markup will be very "terse" (i.e. no
formatting newlines). If they are passed on, then XML applications will
sometimes be working with different data than SGML applications are.

 Paul Prescod

Received on Wednesday, 2 October 1996 23:15:26 UTC