Re: Suppressing ixml:state

Since it was Tom who particular strongly agitated for being able to 
suppress ixml:state, I'd like to hear from him as well.
Steven

On Wednesday 25 May 2022 16:38:46 (+02:00), C. M. Sperberg-McQueen wrote:

 >
 > Steven Pemberton writes:
 >
 > > "Processors may provide a user option to suppress that attribute"
 > >
 > > This was originally included when ixml:state="ambiguous" was the only
 > > possibility. Now we have:
 > >
 > >
 > > ambiguous
 > > failed
 > > prefix
 > > version-mismatch
 > >
 > >
 > > as possible tokens within the value.
 > >
 > >
 > > So what is it we want to allow the user to suppress? Is it only the
 > > "ambiguous" token, or is it the whole attribute?
 >
 > For what it's worth, my recollection is that the rationale for allowing
 > processors to offer such an option while remaining conformant was the
 > desire to cater to people who for whatever reason want the parse tree,
 > the whole parse tree, and nothing but the parse tree in the output.
 >
 > Two obvious subgroups here might be (a) people whose XML would be
 > exactly what their downstream applications expect, except for the
 > out-of-band information we have injected using ixml:state, saving them
 > having to insert a processing step into the pipeline just to strip the
 > attribute; and (b) people who would prefer that differeng kinds of
 > information (result, information about the result or about the process
 > producing the result) come in on different channels. Tom and John,
 > respectively, have stuck in my memory as propounding the views I
 > associate with groups (a) and (b).
 >
 > I think the rationale still holds, and I think it suggests that what we
 > want to allow conforming processors to suppress is the entire ixml:state
 > attribute.
 >
 > Michael
 >
 >
--

Received on Thursday, 26 May 2022 12:30:28 UTC