in situ (or not) changes Re: small comment on the AB draft process document

On Fri, 18 Oct 2013 03:25:03 +0200, Ian Jacobs <> wrote:
> <> wrote:
>> On Fri, 18 Oct 2013 02:10:25 +0200, Ian Jacobs <> wrote:
>>> On Oct 17, 2013, at 6:50 PM, Charles McCathie Nevile  
>>> <> wrote:
>>>> On Wed, 16 Oct 2013 10:44:38 +0200, Ivan Herman <> wrote:
>>>>> chaals wrote
>>>>>> Ivan had written
>>>>>>> 7.6.2, classes #1 and #2 of changes: does it mean that the Working
>>>>>>> Group (or the team) is allowed to make changes on the documents
>>>>>>> directly, in situ, on the TR pages? Or does it mean that a new
>>>>>>> document is created (with a new dated URI) by the Working Group,  
>>>>>>> which is then silently put up on /TR (maybe with a home page  
>>>>>>> announcement)?
>>>>>> This text was inherited from the existing process document. I  
>>>>>> believe the practice is that in the first case the changes can be  
>>>>>> made in situ (although there is a difference between changing the  
>>>>>> invisible content of markup and the actual text of a link, IMHO). I  
>>>>>> am not sure when the second class of change would be made, but my  
>>>>>> inclination is to either remove it, or require an Edited  
>>>>>> Recommendation rather than allowing in situ editing.
>>>>> Actually, I do like what is there, ie, that even #2 changes can be  
>>>>> done in situ. Let me give a typical example: we have a document in  
>>>>> the making (JSON-LD), that has a dependency on Promises (or whatever  
>>>>> the name in vogue is these days). We would really like to publish  
>>>>> this as a Rec today, but the reference to the Promises document  
>>>>> cannot be normative. Say in 6 month the Promises document, in its  
>>>>> current format, becomes final and cast in concrete. That means that  
>>>>> a new JSON-LD document should be issued with the reference changed  
>>>>> to normative. This change would not affect conformance of  
>>>>> implementations, but it is not a broken link or invalid markup  
>>>>> change: ie, it falls under category #2. On the other hand, it looks  
>>>>> like madness to go through the whole hoopla and contacting the AC  
>>>>> over this change, so I would like the team or the WG to make the  
>>>>> change in situ, announce the change and go on with their lives...
>>>> I raised ISSUE-47 for this point. I think that markup changes should  
>>>> be allowed "silently" - i.e. no announcement required.
>>> Here is the Director's current policy:
>> Thanks. I am proposing to bring the Process more in line with this. But  
>> I am still not entirely happy with the section - it is unclear *who*  
>> can request or approve a changeā€¦
> That document says:
>  "Editors (or others) send a request to the Webmaster, cc'ing the domain  
> lead, webreq, and w3t-comm. The request must include:"
> I believe it is intentionally left open. I would not want to constrain  
> it unwittingly.

Nor would I. But in the latest draft (just pushed to public), I  
"wittingly" set expectations of who might do this.

Review and feedback appreciated.



Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex         Find more at

Received on Friday, 18 October 2013 01:28:43 UTC