Re: Suppressing ixml:state

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


-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

Received on Wednesday, 25 May 2022 14:39:03 UTC