RE: [DM] white space

We have seen the data model generation as an application that
understands xml:space="default" and "preserve" and have furthermore
decided that it is up to the upper-specs and implementation to define
what the "default" behaviour is.

I find this logical and consistent. If you want to get the upper-specs
to mandate options to provide both skip and preserve as options, then
please indicate where and how. We will certainly look at this.

Thanks
Michael (speaking for myself, but trying to avoid unraveling the specs
at the wrong place)

> -----Original Message-----
> From: David Carlisle [mailto:davidc@nag.co.uk]
> Sent: Friday, December 05, 2003 1:30 PM
> To: Michael Rys
> Cc: public-qt-comments@w3.org
> Subject: RE: [DM] white space
> 
> 
> > Boundary whitespace (maximal character information sequence that
only
> > consist of whitespace) may be considered insignificant by fn:doc()
if
> > xml:space is not set to "preserve".
> 
> but neither the xml rec nor infoset give any authorisation to call
such
> text nodes insignificamt and drop them It's also mightly inconvenient
> for users when the spaces between words vanish just because words are
> marked up (marking up words in documents being the main point of xml
> after all)
> 
> 
> > And I am (obviously) strongly opposed to changing the semantics for
XSLT
> > 2.0 in a non-backwards compatible way.
> 
> The ony reason that the current behaviour in IE might be considered
> conformant is that it would be conformant for XSLT1 to take every
input
> document as <x>hello world</x> and ignore any xml file, the mapping
from
> input XML  to initial tree is sufficiently lax. XSLT2 here it is
stated
> that
> you are suppoised to parse the document and build an infoset, having
done
> that where does this magic "insignificant" white space come from?
> 
> 
> > If you want to push for a change,
> > please propose it as part of the semantics of fn:doc().
> 
> It applies equally (perhaps more so) to the implicit initial input as
> well as documents loaded via doc(unment).
> 
> David

Received on Friday, 5 December 2003 16:41:04 UTC