W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > April 2009

RE: xml-stylesheet issues--suggested resolutions

From: Grosso, Paul <pgrosso@ptc.com>
Date: Sat, 18 Apr 2009 11:30:54 -0400
Message-ID: <CF83BAA719FD2C439D25CBB1C9D1D3020F43612F@HQ-MAIL4.ptcnet.ptc.com>
To: <public-xml-core-wg@w3.org>
 

> -----Original Message-----
> From: Simon Pieters [mailto:simonp@opera.com] 
> Sent: Saturday, 2009 April 18 5:49
> To: Grosso, Paul; public-xml-core-wg@w3.org
> Subject: Re: xml-stylesheet issues--suggested resolutions
> 
> On Fri, 17 Apr 2009 23:41:54 +0200, Grosso, Paul 
> <pgrosso@ptc.com> wrote:
> 
> > Having reviewed what Arbortext does [1] and (thanks to Henry)
> > what Saxon does [2], embedded herein are my suggestions for
> > clarifications to the Associating Stylesheets Rec [3].
> >
> > In general, we will need to decide if the various error
> > cases are "it is an error (the xml-stylesheet processor
> > may ignore the whole thing, may ignore what it doesn't
> > understand and try to process the rest, etc.)" or "fatal
> > xml-stylesheet error (a compliant xml-stylesheet processor
> > must ignore the entire PI)" or "it is an error; the
> > xml-stylesheet processor must recover by XXXX".
> >
> > In most cases, I'm tempted to say "is an error; the
> > xml-stylesheet processor MAY ignore the entire PI; if
> > it tries to recover, it SHOULD xxxx."  Thoughts?
> 
> I would prefer if for different errors it was either "is an 
> error: MUST ignore the entire PI" or "is an error: MUST 
> recover as follows: xxxx".

We should certainly discuss this.  My feeling is that too
many MUSTs just means a lot of implementations will remain
non-compliant.  In particular, few implementations that
currently accept a certain PI will want to change their
behavior to ignore it--their uses would reasonably be
upset that things that used to work suddenly stopped working.

Remember that SHOULD implies that an implementation needs
to have a "good reason" to do otherwise (where "good reason"
is, of course, undefined), so while an implementation isn't
non-compliant if it does otherwise, there is still some force
of standardization to follow the recommendation.

We can decide for each case what wording to use, but especially 
given the history/legacy involved in this situation as well 
as the fact the browsers are notoriously prone to be lenient 
in what they accept, I fear we'd just lose credibility if we 
said MUST in too many places.

paul
Received on Saturday, 18 April 2009 15:33:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 April 2009 15:33:11 GMT