- From: Michael Kay <mike@saxonica.com>
- Date: Fri, 3 Oct 2025 09:03:20 +0100
- To: Dimitre Novatchev <dnovatchev@gmail.com>
- Cc: Norm Tovey-Walsh <norm@saxonica.com>, public-xslt-40@w3.org
- Message-Id: <03DE5F11-7269-4332-975E-2B680EBE2857@saxonica.com>
> > What is meant by "if it were presented the right way", Dr. Kay? I know you are quite busy, but just expanding a little bit on this via email/DM would be really valuable. > I would suggest three things: First, make the proposal technically complete and unambiguous so it is clear exactly what changes are being proposed to the specs. Secondly, motivate the changes with convincing examples and use cases showing what problems can be solved using the new feature that are difficult to solve any other way. Remember the distinction that marketing people make between features and benefits. A feature of a walking frame might be that the height is adjustable: the benefit is that the user is less likely to suffer a fall. When you say: One of the benefits is that it provides the feature of Lazy (deferred) evaluation as a standard, available and guaranteed capability. Another benefit is that a generator provides a uniform collection-datatype you are describing features, not benefits. You need to describe convincing examples of problems that can be solved using these features. Thirdly, try to cut out the antagonising rhetoric: "Do we think about the end users of XPath at all?". You need to understand that questioning people's motivation and commitment automatically puts them on the defensive and makes them less likely to see the the merits of what you are proposing. You won't be able to counter people's objections to a proposal unless you understand and respect those objections; if the objections arise because people don't understand what you are proposing at a technical level, then the onus is on you to explain and educate. Michael Kay
Received on Friday, 3 October 2025 08:03:37 UTC