Re: spec question xml:space=preserve

I believe region is NOT a content element, but defines a layout
specification, which, in XSL-FO terms, would be an fo:block-container (as
you note).

I believe there is no problem with respect to preserved whitespace inside
region, since, according to 9.3.2 (1), only text nodes in a content element
are subject to being treated as anonymous spans.

I suppose your last question is whether we should modeify the phrase ³that
is not a child of a span element², yes?

In other words, I guess you are suggesting that the following:

span
  sequence of text nodes ³ABC²
  span
    sequence of text nodes ³DEF²
  sequence of text nodes ³GHI²

should be rewritten by 9.3.2 (1) to:

span
  anonymous-span
    sequence of text nodes ³ABC²
  span
    sequence of text nodes ³DEF²
  anonymous-span
    sequence of text nodes ³GHI²

So perhaps the language of 9.3.2 (1) should be modified and expanded to the
following three rules:

> a) for each significant text node in a content element, synthesize an
> anonymous span to enclose the text node, substituting the new anonymous span
> for the original text node child in its sibling and parent hierarchy;
> 
> b) for each contiguous sequence of anonymous spans, replace the sequence with
> a single anonymous span which contains a sequence of text nodes representing
> the individual text node children of the original sequence of anonymous spans;
> 
> c) for each span element whose child is a single anonymous span, replace the
> anonymous span with its sequence of child text nodes;
> 
G.

On 12/9/08 6:24 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:

> Fair enough, but that leads to the question as to whether region is a content
> element? It¹s not in the content matter section so I perhaps not, but it has
> some content like behaviour defined in 9.3.2, so is whitespace significant in
> a region?
>  
> If region is considered a content element, then per 9.3.2, it maps to
> fo:block-container, which cannot take fo:inline as children so we would need
> more elaborate processing.
>  
> I also wonder, given we now allow nested spans, whether the first rule of
> 9.3.2 needs updating:
>  
> ³for each significant text node in a content element that is not a child of a
> span element, synthesize an anonymous span to enclose the text node,
> substituting the new anonymous span for the original text node child in its
> sibling and parent hierarchy;²
>  
>  
> 
> Sean Hayes
> Media Accessibility Strategist
> Accessibility Business Unit
> Microsoft
>  
> Office:  +44 118 909 5867,
> Mobile: +44 7875 091385
>  
> 
> From: Glenn A. Adams [mailto:gadams@xfsi.com]
> Sent: 09 December 2008 04:09
> To: Sean Hayes; Public TTWG List
> Subject: Re: spec question xml:space=preserve
>  
> 
> Since xml:space has semantics irrespective of presentation processing, and
> since xml:space is generally permitted by XML itself on any element, then it
> should not be an error to specify on any element in DFXP. Note the last
> paragraph in DFXP CR 7.2.3.
> 
> 
> On 12/9/08 8:32 AM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
> In DFXP should it be considered an error to use xml:space on elements other
> than span and p? 
>  
> My thinking is that if text creates anonymous spans, surely these should only
> be allowed where spans are allowed?
>  
> 
> Sean Hayes
> Media Accessibility Strategist
> Accessibility Business Unit
> Microsoft
>  
> Office:  +44 118 909 5867,
> Mobile: +44 7875 091385
> 
>