Basically I don't agree that a spec should only be readable by the people who wrote it.
A well-structured and well-written spec should allow anyone to read it. If a spec is not readable even by technologists, it will be counter-productive for the technology itself because it could not be endorsed.

The W3C is full of Primer success documents, such as RDF, OWL, and so on. I think there is a place for W3C tutorials and for book detailed tutorials with plenty of use cases.

Best Regards

Michael Kay escribió:

My comment about the XPATH 2.0 TR is that it is not easy to 
see at first glance what are the differences between 1.0 and 
2.0 versions. Also I'm missing an "XPATH Primer" for the 
clueless reader.


A personal response:

Concerning differences between 1.0, it would have been nice to provide this
information but it would have been a very long list, and it would have been
difficult to ensure its accuracy. We felt it more important to concentrate
on areas of incompatibility, which are covered in Appendix I.

Regarding a primer, we took the conscious decision that it was best to leave
provision of tutorial material to the market. This makes particular sense
for version 2.0 of a specification. The W3C process is not a good way to
write and publish tutorial material, because it has to be discussed in
committee and voted on. You can get books on XPath 2.0 (for example, my own
from Wiley) which attempt to meet this need. A book author can say helpful
things that a W3C working group can't say, for example "this feature is
implementation-defined, but as far as I know everyone except Microsoft does
X".

In my XPath 2.0 book, each section describing an XPath 2.0 feature has a
subsection "Changes from XPath 1.0" which explains what's new.

Generally, W3C specifications (like those from most standards bodies) are
not designed to be read by clueless readers. Their purpose is precise
specification of a language, and this can often make them difficult to read.

Michael Kay
http://www.saxonica.com/