Sorry about that... finger trouble ! It seems that with the exception of the few obvious name clashes we can just go ahead and create pages. If later we discover a clash then we will need to change the page name accordingly. Assuming you use the normal wiki link markup cwiki fixes the link changes.
Where their is an obvious cross area topic/chapter we can just prefix the page name with something appropriate... a couple of examples: The "Introduction" for the "SCA in Java User Guide" would become "SCA Java User - Introduction"... The "Introduction" for the "SCA in CPP Developer Guide" would become "SCA CPP Dev - Introduction"... Most page names are unique enough. For example "Obtaining Tuscany's Java SCA Implementation" is a user guide document (currently) but the name is unique enough not to worry about prefixing it... and besides it might also want including elsewhere. So, as general guidance, if we write a document with a name that is obviously going to clash with another in a different domain... prefix it.... otherwise don't bother. There is a minor "bummer" about prefixing, but it only effects us if we use some of the macros (we can't avoid having the prefix visible)... but this seems a minor concern given the complexity of multiple spaces. I had stopped writing (pending a "conclusion" on this thread), but now I'm going to get back to it... WDYT ? On 13/02/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
Hi, In line with what Simon put above, it would seem sensible to try to prefix pages (as setting up extra spaces for a lowish number of pages does seem like an overhead) So... for SCA Java specific pages we prefix the page name with "SCA Java" Topic On 11/02/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > On 2/10/07, haleh mahbod <[EMAIL PROTECTED]> wrote: > > > > Ah. You add a good point that we need to think about extension > documents > > as > > well :) > > > > On 2/9/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > > > > > On Feb 9, 2007, at 4:56 PM, haleh mahbod wrote: > > > > "Extension developer would generally not work off the latest code > (I > > > > generally discourage people from doing this as the state of trunk > may > > > > be in flux). They would tend to go off a published release." > > > > > > > > OK. Although it seems like all discussions are typically centered > > > > > around > > > > the latest code on mailing list. > > > > Maybe this is what we should encourage. > > > > > > When you munge everything together it can be hard to tell. Most of > > > the technical discussion recently has been around changes to the > > > kernel rather than extensions and so naturally relates to the latest > > > kernel code. If we did have discussion around an extension, it would > > > > be about the latest code /of that extension/. > > > > > > -- > > > Jeremy > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > So, from this thread, a number of things that partition our > documentation. > > Underlying technology: Java, C++ > Project: SCA, SDO, DAS > Module(?): Kernel, Runtimes, Extensions... > Release: M1, M2, M3 (are the next releases going to be at the module > level > now?) > Reader: User, Extension Developer, Developer > > It seems that the Cwiki is shaping up as follows: > > SCA > Java > User pages > Intro > Installing > Samples > Building an app > What extension are available > Etc… > Developer pages > Intro > Architecture > Dev env > Module docs > Etc… > C++ > FAQ - not sure why this is at this level? > SDO > Java > C++ > FAQ > DAS > Java > C++ > FAQ > > > It's difficult to comment on whether developer docs should be separate > from > extension developer docs but if feels like it's a low priority at the > moment. We should make space to describe the separate modules that are > available both from user and developer perspectives. > > Is there still going to be a full milestone release at some point where > documentation is built or are the separate modules going to advance > independently? This will flavor how we keep track of what we are writing > docs for. As we are still in incubation can we continue just to worry > about > the latest code? I like the idea of using new spaces to represent > documentation for major releases but that doesn't work for finer grained > releases. We need a way of marking which details relate to which > version. > Confluence themselves label pages, e.g, ( > http://confluence.atlassian.com/display/DOC/Administrators+Guide), but I > don't know how they use the labels exactly yet. > > As Dan pointed out page names must be unique within a space but this > doesn't > cause particular pain in our PHP site as we just prefix page names. We > do > have a very small number of pages though. We also use the Left > Navigation > theme. This provides a left hand menu like they have on CFX ( > http://cwiki.apache.org/CXF/) as Shelita noted. Changing the theme is a > space admin task. If we want this is Ted Husted the man to talk to? Does > > anyone from Tuscany have space admin privileges? > > Simon >
