Re: The red box on the XPath 1.0 spec

On Thu, 2016-09-29 at 17:25 +0200, Abel Braaksma wrote:
> I agree to the proposals.
> 
>  
> 
> I remember that in February I wrote a document that listed the
> current inconsistencies of URL naming. I believe that we concluded
> that on /TR/xslt, /TR/xpath etc we would create an indexed document
> and add /TR/xslt10, /TR/xslt-10 etc as redirects to the appropriate
> standards. I think that is also precisely what Michael suggests
> below.

Unfortunately the publication system W3C has poses some constraints
that may not make this as easy as it sounds.

(1) changing a shortname involves republishing; it's not necessary to
go through transition calls etc., but the documents will get a 2016
date; In some cases redirects can be changed, but not actual
shortnames.

(2) shortnames have some lexical constraints - I don't know all of
them, but when we tried to make them conistent before, it wasn't
possible. It would also have required republishing (including e.g.
XPath 1 and 2) which is why we dropped it when I reported back to the
joint working groups about it. I think one constraint was not being
able to (re)publish a document whose shortname is a prefix of one
already in use, so republishing XPath 1 wasn't possible; I can go back
and check but it's probably best to come up with a proposal and then
ask the Webmaster what's possible - which is actually what was done
last time round, so please do it in conunction with XQuery, since
they're affected by the shared specs and by the shortname of XPath 1.
Carine may know more than I do about the current constraints.

(3) changing the status section, introduction, or actual text of a
document requires republishing, again giving the document a new date.

(I don't like the new date that appeared on XPath 1 either! I hadn't
expected it, but it was better than making a new "latest version" of
XPath in /TR/2015/ by far)

(4) I think I can get away with changing the text in the boxes without
being noticed or beaten too hard :-). I'm certainly open to fixing any
mistakes in there. We were allowed to put the text there under the
proviso it was in a big red box clearly distinct from the text.

The boxes were put in place as a result of ACTION A-592-02 from the
joint XSLT/XQuery meeting:
https://lists.w3.org/Archives/Member/w3c-xsl-query/2014Dec/0053.html

Note that in that meeting Michael Sperberg-McQueen some wording (I
don't remember whether his suggestion was used or if not why not; the
meeting didn't adopt the change in a recorded decision).

I'd certainly like /TR/xpath10 to go to XPath 1 rather than an error,
since xpath20 goes to 2.0

Liam

>  
> 
> For reference, the list of current inconsistencies can be found here:
> https://lists.w3.org/Archives/Public/public-xsl-wg/2016Mar/0007.html,
> it may still serve a purpose to check whether they work correctly
> after the redirects are in place.
> 
>  
> 
> Cheers,
> 
> Abel
> 
>  
> 
>  
> 
> From: Michael Kay [mailto:mike@saxonica.com] 
> Sent: Wednesday, September 28, 2016 6:48 PM
> To: Public XSLWG
> Subject: The red box on the XPath 1.0 spec
> 
>  
> 
> ACTION 2016-09-22-002 MK, MSMcQ, Abel: Come up with proposed
> language to replace the "red boxes" in the 1.0/2.0 specs;
> Sharon to merge/edit the proposals, then ask Carine to implement
> the proposal. (XPath 2.0 and beyond need liaison with XQuery WG).
> 
>  
> 
>  
> 
> I think the main problem with the "red box" is not the actual text it
> contains, but its "in your face" impact.  It is designed to alarm the
> reader, and I think it does so unnecessarily.
> 
>  
> 
> Procedurally, I think it can be argued that we agreed that the text
> should be added, but didn't agree that it should be quite so
> aggressively presented.
> 
>  
> 
> Also, I think the "revised 7 September 2015" at the top is
> misleading: there is nothing to tell the reader that the only
> "revision" on that date was the addition of the red box.
> 
>  
> 
> My proposal:
> 
>  
> 
> (A) Delete the red box. Replace it with a paragraph at the end of the
> status section, in normal font, perhaps with a low-key box around it
> to signal that it is a later addition, that says:
> 
>  
> 
> Status Update (October 2016): Although XPath 1.0 remains widely used,
> and is referenced normatively from other W3C specifications, readers
> are advised that later versions exist, and that no further
> maintenance (including correction of reported errors) is planned for
> this document. Readers interested in the most recent version of the
> XPath specification are encouraged to refer to  <http://www.w3.org/TR
> /xpath-3/> http://www.w3.org/TR/xpath-3/.
> 
>  
> 
> (B) in the subtite, change "revised 7 September 2015" to "status
> updated October 2016".
> 
>  
> 
> Ditto for XPath 2.0 (Objections here are arguably stronger, since the
> latest XSLT Recommendation refers normatively to XPath 2.0)
> 
>  
> 
> (C) Short names:
> 
>  
> 
> The right thing is surely for /TR/xpath/ to point to a short index
> document that lists the different versions of XPath, and for the
> short names
> 
>  
> 
> /TR/xpath10/
> 
> /TR/xpath-10/
> 
> /TR/xpath20/
> 
> /TR/xpath-20/
> 
> /TR/xpath30/
> 
> /TR/xpath-30/
> 
>  
> 
> to get you to the specific Recommendation versions.
> 
>  
> 
> Of course the indirection of /TR/xpath/ to this index document will
> change the semantics of some existing links (e.g. the Wikipedia
> article on XPath 1.0) but they will get updated over time.
> 
>  
> 
> Michael Kay
> 
> Saxonica
>

Received on Thursday, 29 September 2016 18:44:52 UTC