RE: RS/RE, again (sorry)

What I had in mind is a *manual* process:
the user marks his element and this is why I was proposing *one* value:
PRESERVE.
in the manual process, using 3 values becomes cumbersome.



>----------
>From: 	Michael Sperberg-McQueen[SMTP:U35395@UICVM.UIC.EDU]
>Sent: 	Friday, December 13, 1996 12:24 PM
>To: 	Tim Bray; W3C SGML Working Group
>Subject: 	RE: RS/RE, again (sorry)
>
>On Fri, 13 Dec 1996 15:14:05 -0500 Tim Bray said:
>>I support Jean's position, that we leave -XML-SPACE in, and either
>>cut it back to one value (COLLAPSE) or expand it to three values
>>(PRESERVE, COLLAPSE, REMOVE), but change its meaning so that it acts
>>as a signal from the processor to the application, but that the
>>processor *always* in all cases passes all the bytes through to
>>the app.
>
>Does this mean a validating XML processor should both pass through
>all the bytes (n.b. this *still* isn't all the bytes, unless you
>want me to pass you the white space and quotation marks in the
>interior of start-tags, which you just aren't going to get, not
>from my parser), *and* use its knowledge of the DTD to add an
>appropriate -XML-SPACE attribute spec before passing the data to the
>app?  So an XML processor which emits sgmls-output-format data might
>read
>
> <?XML version='1.0' encoding = 'iso646' RMD='internal' ?>
> <!DOCTYPE list [
> <!ELEMENT list (item*) >
> <!ELEMENT item (#PCDATA | list)* >
> <!ATTLIST
> ]>
> <list>
>
> <item n=1>
> this is the first item</item>
>
> <item n=2>this is the
> second
> </item>
>
> </list>
>
>and emit (I assume some tabs and space in invisible locations)
>
> A-XML-SPACE TOKEN REMOVE
> (LIST
> -\n\n
> AN CDATA 1
> A-XML-SPACE TOKEN PRESERVE
> (ITEM
> -\nthis is the first item
> )ITEM
> -\n\n
> AN CDATA 2
> A-XML-SPACE TOKEN PRESERVE
> (ITEM
> -this is the       \nsecond\n
> )ITEM
> -\n\009\009\009\n
> )LIST
>
>A processor which doesn't read the DTD would emit the wrong values
>for -XML-SPACE some of the time (it would always say #IMPLIED or
>something).
>
>Is this what you have in mind, or something different?
>
>-C. M. Sperberg-McQueen
>
>

Received on Friday, 13 December 1996 17:01:41 UTC