[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: whitespace in 1.1

Re:  whitespace in 1.1
>In my experience, the words "as if" are often a signal that something is
>badly wrong in a spec.

I disagree.  An "as if" description is often the most straightforward
way to describe something.  The XML line end normalization description
is in fact a good example of this.  The original 1.0 text said:

  To simplify the tasks of applications, wherever an external parsed
  entity or the literal entity value of an internal parsed entity
  contains either the literal two-character sequence "#xD#xA" or a
  standalone literal #xD, an XML processor must pass to the
  application the single character #xA. (This behavior can
  conveniently be produced by normalizing all line breaks to #xA on
  input, before parsing.)

Unfortunately, it turns out that normalizing on input is *not*
equivalent to the conversion described, because of the possibility of
using character references in entities.  So the spec was
contradictory.  Furthermore the normalization-on-input version is the
one that most processor use.  In an attempt to be declarative rather
than procedural, it instead was inconsistent.

> Saying that it behaves for some purposes as it it normalized them and
> for other purposes as if it didn't is a sure path to ambiguity, and a
> sure signal that the processing model has not been adequately defined.

But it doesn't say that, except maybe as a result of carelessness if
you agree with John.  The intention is that it behaves as if it normalized
line ends on input, for all purposes.

>In all these cases the problems would be avoided by describing a
>processing model in which the stages of processing (of an object such as
>a stylesheet) are explicitly described, and constraints are defined on
>the object at a specific stage of processing.

Fine, but if these stages are internal to a process such as parsing,
there is no way for the user to tell whether it's implemented like
that or in some equivalent way.  And in that case, there is no reason
to require it a particular implementation method (nor is there a way
to test it).

The only point of "as if" is to avoid prohibiting alternative,
indistinguishable, implementation methods.

I would prefer the whole spec to be wrapped in "as if", rather than
introducing it for specific points.  The ISO C standard works that way.

-- Richard


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.