[pmwiki-users] Permissions conundrum, section behaviour

[Patrick R. Michaud]

On Thu, Oct 05, 2006 at 06:59:37PM -0400, Henrik Bechmann wrote:
> If I could press just a little re: delimiters,

Sure, press on!  

My responses here are likely to be a little terse because I'm
in a rush to get somewhere else and might not have time later tonight
to answer... so, take them with a grain of salt.

> - Delimiters provide explicit attributed identification so that the 
> blocks would be available for other applications, including 
> section-edit ...

I think that section-edit should be able to infer sections from
natural markups within the page (e.g., headings and divs) rather
than require a markup for each section to be edited.  

> but also for application extensions (cookbook recipes) 
> that would be able to take advantage of the structured naming, typing, 
> and parameters. I don't quite see how anchors could provide the same 
> level of information. Could they? Are you planning to allow attributes 
> for anchors?

I wasn't planning to allow attributes for anchors but I don't
see any particular reason it can't be done if we need it:

    [[#anchor abc=xyz]]

> - Delimiters and anchors are orthogonal: delimiters are an application 
> construct; anchors are an HTML construct. 

I agree with the notion that "anchors are an HTML construct".  
The way PmWiki uses [[#anchor]] is to identify specific locations 
in a page, and pairs of anchors can be used to identify
full blocks of a document.  The fact that these happen to translate
into <a id='...'></a> is a significant part of what we're
doing, but [[#anchor]] already means a lot more to PmWiki than 
simply "HTML construct".  (The two obvious examples are
the fmt= parameter to pagelist templates and (:include Page#section:) ).

> I am concerned that combining them may be more confusing for 
> users than separating them.  

Possibly, but when it makes sense I prefer to re-use existing
markups as opposed to creating new ones, especially if they're
closely related.  I think our difference in viewpoints comes
down to...

> - Delimiters, if named with the standard "section" name ([!section 
> comment...!] or (:section comment...:)) are explicit and coherent, 
> whereas it may be hard to differentiate anchors applied to section 
> blocks from HTML anchors, etc.

I don't see that differentiation is needed.  I'd need to see
a clearer example of the markup advantage of 

   (:section comment ...:)
   alpha beta gamma
   (:section:)

over

   [[#comment ...]]
   alpha beta gamma
   [[#commentend]]

> - Delimiters form a conceptual coherent delineated balanced pair with 
> matching directives. 

I'm also not certain that delimiters need to be paired or balanced.
We can already use [[#xyz]] to refer to a block of text.  We can 
already use pairs of anchors to refer to arbitrary (and indeed,
unbalanced) sections of text.  So, it seems like the only thing
really missing would be to have a way to 


Ultimately I prefer [[#section]] over (:section:) because

  - A url ought to be able to specify a certain section of a page,
    and the url syntax for that is #section
  - We already have a history of using the [[#xyz]] markup to
    delimit sections of a document, such as in pagelist templates
    and includes
  - I think if we introduce a separate markup construct, we'll
    have trouble explaining to authors when they should be using
    one over the other.

But I think I need to see some concrete examples of why the
other would be more beneficial.

> Directives such as (:commentaction parm parm parm:) 
> provide the behaviour instructions; delimiters with attributes such as 
> -- (:section comment:) text (:sectionend:) -- provide the clear matching 
> output.

I've thought a *lot* about things like (:commentaction parm parm parm:)
the past week or so (including a test implementation or two), and
I haven't found that it is simplifying or resolving the authorization
issues I see, while it is definitely adding some complexity to the
overall solution space.  Somehow it just doesn't "feel" like the
right answer to me.

I may ultimately be wrong about that, but we should find that out soon
enough.

Thanks!

Pm