W3C home > Mailing lists > Public > public-qt-comments@w3.org > December 2016

[Bug 29984] [XSLT30] Lessen the restraint on required raising of XTSE3430 for constructs not guaranteed streamable per our rules

From: <bugzilla@jessica.w3.org>
Date: Thu, 08 Dec 2016 02:39:29 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29984-523-jgi5q5Ndxn@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29984

C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cmsmcq@blackmesatech.com

--- Comment #5 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> ---
Most of the users I talk to are quite ready to accept that an equivalence
obvious to a human is not necessarily obvious to a machine, and that attempting
to extend a simple set of rules to cover even one or two such equivalences will
quickly render it no longer simple.  But perhaps the users I speak to are, like
myself, not
typical.

Speaking for myself, I as a user would prefer stylesheets in category B to be
streamed, with messages informing me that this and that construct are not
guaranteed streamable, although for this implementation (hurrah) they are
streamable in fact.  If however I am forced to choose between giving up the
messages or giving up the streaming, my preference is to give up the streaming.
 Other users may have less wariness of being locked in to specific
implementations.  (MAY?  Looking at user behavior, it's quite clear most users
have no objection at all to lock-in, until it's too late.)

I would not like to push implementors too far, because I'm acutely conscious of
the risk MK identifies, of not getting any conforming implementations.  But
given a set of implementations which don't do what I think is the right thing
(and which has been a fundamental principle of our design since 2007), and
given the choice between  defining conformance to include or to exclude those
implementations, I think we would do better to make them non-conforming. 
Conformance rules can't force an implementation to do something the implementor
doesn't want to do, but in some ways the definition of conformance is the only
thing a WG has -- either we make it a useful concept for doing the kinds of
thinking and talking users and others need to do, including talking and
thinking about interoperability, or we make it useless. It's a threat I don't
like to use, but I do think there is a risk that if conformance offers
interoperability guarantees that are too weak, there might be WG members who
will object to progressing the specification.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 8 December 2016 02:39:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:03 UTC