SectionedPage

MeatballWiki | RecentChanges | Random Page | Indices | Categories

[For the original context, see CategoryCategoryDiscussion, which mentions moving categories into a separate section. Briefly, a wiki page will be a collection of named sections, like "main" (for the main text), and "category" for the category information. Other sections may be added later, and eventually ViewPoint will use sections.]

: SectionedPages will be part of 0.90, although they might not be user-visible in that release. [It's now very unlikely that any user-visible section-related changes will be done in 0.90. KeptPages and the other planned enhancements will be plenty.]

Question. How is a SectionedPage superior to InternalTransclusions? I mean, really, a sectioned page is simply a sequence of InternalTransclusions of pages (possibly anonymous, but not really). It is more powerful and probably just as simple to make the sections separate pages which are emitted together, as you can include the same section in two different pages. You can also create a directed acyclic graph of pages. You'd have to be careful to break cycles, of course.

Note, for an example of how you can emit two types of pages together, click on the diff link at the bottom of the page. You get the QuickDiff? + a preview of the page emitted together. [Actually, difference display is an option of the ordinary page display. It's pretty close to the section idea, where one could choose to display or hide sections.]

: I'm not sure the intent is to go so far as to allow one to include a page or portion of another page using sections. It seems to me that it is simply a better way to break up different types of page content. I think of it as analagous to the intro-text and body-text conecpt Advogato and Kuro5hin use for their articles; the intro-text is all that appears on the front page, but both intro- and body-text appear on the article page. I.e., all pages will have the same set of sections, rather than being able to create an arbitrary set of sections on a particular page. Hence, its benefit in dealing with categories; each and every page has a body-text section and [at least] one categories section. This begs the question: since Cliff is implementing SectionedPages, how much effort would it take to go whole-hog and do InternalTransclusions? -- anon.

This is pretty much the right idea, at least for the initial implementation. (Later people should be able to add non-standard sections and choose to display them.) TransClusion seems very nifty until people actually put it into practice. Implementing transclusion would be a significant change to the current structure of "open only one page per query", but it wouldn't be impossible.

The bigger problem is the interfaces for transclusion. One might start with full-page transclusion, but people will quickly ask to transclude only sections of a document. Then you need to add sectional markup. Seamless transclusion (no borders) makes editing the transcluded material more difficult. Limits of transclusion need to be documented, and error-handling implemented for situations like cycles. (Consider pages A, B, and C. A transcludes B, and B transcludes C. Now if someone edits C to transclude A, one has a cycle. There is nothing within page C to indicate that others are transcluding page C. One needs a full backwards graph to find cycles at edit time.) Of course all of this also needs to be documented...

If people can come up with real examples where TransClusion would be better than existing solutions, I'll reconsider it. Eventually, a future version of ViewPoint should allow assembling pages from arbitrary sections on different pages. Finally, all other things being equal, better is better. Worse-existing tends to be better than better-planned-for-future-version, however. --CliffordAdams

: Can't think of any pressing need. Wiki seems to get along just fine without transclusions. Come to think of it, I wonder whether transculsions would actually detract from WikiNature?? -- anon.

I was also concerned about possible negative effects, especially for whole-page transclusions. For instance, suppose there was a Definition-Of-Transclusion page containing just a brief definition, and it was transcluded in several places. Now suppose someone inserts a long comment on the definition. This could degrade several pages. Where should the person add their comments?

: People could add comments in a "discussion" section. There could also be a short "summary" section in addition to the "main" section.

On the positive side, ZWiki:FrontPage seems to be the best use I've seen of wiki TransClusion. I'm not sure if it is greatly better than the usual current/archive split, however. --CliffordAdams

I wonder what SectionedPages add in the first place. Am I correct in assuming you are trying to preemptively optimize KeptPages?

: Not quite, although it does simplify some aspects of KeptPages. (I can simply append the section-string to the keep-file to make an archival copy.) The biggest reason is that the section-based storage should be sufficient for the (eventual) ViewPoint work, without disrupting "ordinary" wikis. Since ViewPoint is my main interest, I would rather not have to maintain a separate "classic" wiki db. In a sense, a "classic" wiki is simply a ViewPoint system with only one view (and with all the multi-view interface elements hidden). I'd also like to make it easy for a site to start with an ordinary wiki, then move over to a ViewPoint system if the community grows enough to support it.

: Some of my decisions for KeptPages will make the 0.90 upgrade not-quite transparent. For instance, it looks like the upgrade will toss out the old copies of pages, and treat all pages as if they were freshly entered with their current content. (The current (0.88) db keeps only the old text of the page--it does not save the old revision, author, or timestamp info. Rather than add legacy-case code (to deal with missing information), I think it's better to just wipe all the old diffs at the time of the upgrade. I will keep the current revision number, author, and edit time intact, however.) I want to minimize the number of disruptive upgrades, but I think the minor inconvenience now will be worthwhile later.

: The 0.90 upgrade will be the second major DB change. One older version of the DB actually used something much like sections for its old versions--when a page was edited it just copied the entire current DB contents to a list of older versions. I almost thought of something like KeptPages, but I kept only a fixed number of edits. The change from the old->0.86 DB was transparent, but at the cost of about 20 lines of code. (This code will be moved from the main script into the 0.90 update-conversion script.) --CliffordAdams

In other news, I have some design notes for the sectioned-db at MbTest:SectionDesign. It really isn't much of a change from the old DB, which was far more generalized than necessary. --CliffordAdams

Another use of this would be to impose variable (context-sensitive) meta-structure on top of the actual content of a page. For example, say you want to add next/previous links to pages to make discussion of certain subjects more linear. As DaveHarris points out on BookMetaphor, if any given page is included in more than one linear thread, then it would have multiple next/previous links. Ideally these sort of things could be hidden from the user unless the user asks to see them or unless they are browsing a linear thread. This requires logic in the server, and I think it could be done cleaner by way of SectionedPage. -- BayleShanks

: Something similar has been done at the Go wiki, SenseisLibrary, called "Paths". See SenseisLibrary:HowPathsWork. The path main page references the other pages on the path; the server knows what path you are on, and therefore creates the navigation links for you automatically.

wow, beautiful implementation too -- available paths are shown in a sidebar to the left, and it look like it is very easy to create a path (change the "page type", and then use a special linking syntax) -- BayleShanks

I implemented this concept - specifically for the purpose of TransClusion of (called named sections for includes) in OWikiClone (a derivative of Twiki and usemod) mid 2003. Prior to this I'd used InternalTransclusion of pages for similar effect (I still use the latter for some uses purposes). Some minor points on the implementation there:

Users are require to explicitly denote the start and end of sections
These can overlap and start/stop at the same points (They don't have to be nested, but can be)

As a secondary point, direct editting of sections is enabled for many (not all) sections.

The results of doing this are intriguing :

Manipulating large documents in the wiki becomes relatively simple. Whether this is a good/bad thing is an exercise for the reader to decide
Rather than have a proliferation of small topics for partly formed ideas, it becomes natural to have a large collection of small sections that can grow and spin off into topics. http://owiki.org/OffTopic - is a bit like an IdeasToPlace? page, but with greater detail than that idiom encourages.
The ability naming sections is very useful - you can pull quotes with context from topics and if the quote/topic changes you keep consistency.
Being forced to name sections however is a bind - and fairly user/writer hostile. Various ideas on PurpleNumbers? and other FineGrainedAddressing? ideas become very attractive after a while. (implicitly named sections)
By allowing which sections to be pulled in via preferences, users can customise their interface

On a deeper level I'm struck by the idea that a "page" in normal wiki parlance is actually just a way of having the smallest addressable piece of text in the wiki. However that unit of addressing depends on whether the site prefers small pages (favouring linking) or large pages (favouring discussion, discourse, summaries). This has led to one simple thought:

Suppose you wanted to create a glossary using a wiki (not so odd - most places have local jargon!)
You could create a page per item, or a single page with the entire glossary.

If you use one page per item, you can end up with detailed (useful) pages, on each item. However then it becomes more like wikipedia than a glossary. However if you have a single page, you lose the ability to directly link to the definition. With a SectionedPage you /begin/ to gain the ability to mix the metaphors - the ability to put pages inside container pages, and the ability to directly access them. Put bluntly - if I name a concept on a page it forms a logical section in no different a manner from having a physical page. Why not allow automatic wiki linking to such sections? For example if I type BroadcastingAndMonitoringNews? it would be nice if it linked to that section on UdellOnGroupware directly, but at present I haven't seen any wiki that will do that for me without breaking the page up into lots of smaller pages, thereby breaking the context. (I'd be curious to see one :) This then naturally leads to a fluidity that can allow sites to consolidate small topics to larger ones as time progresses. -- MichaelSamuels

: You can use PageAliases to do this (in OddMuse, for example).

This page is sort of related to PersonalCategories.

[CategoryWikiTechnology] [CategoryUncommonWikiTechnology]