Sunday, November 29, 2009

Textml - an xml shorthand for your text files

The idea

A shorthand that can be used to mark up text in text files but which is easier to handle than writing full-blown xml.

Why bother?

Sometimes I'd like to be able to document things in a text file - from a todo list, to a plan, to documentation on something. I'd like to be able to add slightly richer structures to my text documents. If you use text documents and text editors, you might find this a reasonable idea.

Quickstart

You create tags like this:

  @plan {
    Here is a plan.
  }
  => <plan>Here is a plan.</plan>

Add attributes like this:

  @plan {
    @date: 24-Nov-09
    Here is a plan.
  }
  => <plan date="24-Nov-09" >Here is a plan.</plan>

I often find myself wanting to create a tag context but using long-winded names eg
  @tasks {
    @finish-by: 24-Nov-09

    hosting agreement {
      - do X
    }
  }
  

In this example "hosting agreement" is not necessarily something I want to be a tag. It's not so much the tag as the content of the tag or one of its attributes. As a result, I leave off the '@'.

Now it's up to the context to define how we interpret this structure. Let's suppose we were writing an xml converter for this textml document, then we might define a rule like this: "For non-'@' sections under @tasks, convert to:"

   <task finish-by="24-Nov-09" >
     <issue>hosting agreement</issue>
     <ul>
       <li>do X</li>
     </ul>
   </task>
  

A lot of the time you probably don't ever want to convert textml so your brain applies something similar to the above rule although without all the detail. In your mind you simple say "This is a section about ... ".

I find myself using this above shorthand a lot since I don't want to write in the extra context every time I start up a new section and textml is already doing a good job of providing context within which this shorthand is used.

Paragraphs

The main motivation for textml was to work with text files. so the issue of whether to insert paragraphs tags around each paragraph is a non-issue. You don't bother. You might use a blank line to break them up instead.

However, if you were wanting to convert to real xml, you might want to consider some sort of hinting system. A hint would work within the tag you set it and would probably be inherited. This hint would direct the parser to insert paragraph tags under certain conditions, or not to.

  
    @some-tag {
      #'auto-paragraph 1

      Sentence 1.
      Sentence 2.

      Sentence 3.
    }
    =>
    <some-tag>
      <p>Sentenxt 1.  Sentence 2.</p>
      <p>Sentenxt 3.</p>
    </some-tag>
  
  

In the above example "#'" signifies a hint which has been set for @some-tag. This hint tells the parser to generate paragraph tags around content and to start a new paragraph after 1 empty line.

Bullets

Before I used textml, I used bullets - usually hyphens or asterisks in my text files. The same applies in textml. Use hyphens to create unordered lists. Indentation is assumed to be important. Note how the 2nd @description is indented the same as the string "item 1".

  - item 1
    - item 1.1
      @description {
        Description about item 1.1
      }
    @description {
      Description about item 1.
    }
  

The following attempts to make it more explicit and to remove reliance on the significance of indentation, but I don't think it will catch on:

  -{ item 1
     -{ item 1.1
        @description {
          Description about item 1.1
        }
      }
      @description {
        Description about item 1.
      }
   }
  

Numbered bullets might take the following form:

  # item 1
    # item 1.1
      @description {
        Description about item 1.1
      }
    @description {
      Description about item 1.
    }
  

Converting to xml

The point of textml is allow you to add structure to your text files. For the sorts of things I work on, I don't need to publish what I'm doing into xml.

However it would be fairly straightforward to write script or parser to generate the appropriate xml. Then transform that xml using xslt into other xml-based formats such as xhtml.

Benefits

  • It's easier to date things, sign things, or otherwise add some sort of meta data to something to give you extra information about what you were doing in your text file, when and why etc
  • Makes it easier to explore using xml to create structure or semi-structure. I'm interested in this because I'm looking at xml to represent certain types of knowledge and learning - think of dialectics, assignments, forums, q & a. textml makes it easy to play with some of this straight away in your text editor.
  • Once you've defined a "context" - a parent tag or hierarchy with attributes, you don't have to constantly remind your audience about it. Textml allows you to create structure within your text documents which defines context; once that's out of the way you can concentrate on the specific issue. For instance If my tag is
      @plan {
        @start-date: 24-Nov-09
        - Do X
        - Do Y
      }
     
    A context of a plan and its start date has already been set. Everything I write is within that context.

Limitations

  • A text file is not a web-based document so you can't show images.
  • You are confined to the linear format of a text file; in a browser you can potentially break things up a bit more as well as insert hyperlinks. If you're wanting to do that, you should work with real xml or xhtml in a browser or other capable user-agent.

Friday, May 15, 2009

Javascript packaging and namespacing standard - moved

Back in February 09 I posted an article on a standard for for creating javascript projects which avoided polluting the global namespace and tried to provide a clean way to utilise multiple javascript libraries from multiple authors without gettng clashes in versions and global variables. I've now moved this to http://js.web17.com.au/specs/packaging-and-namespacing/index.xhtml.

Thursday, March 19, 2009

Locales in Linux / Debian

Locales in Linux / Debian

I was updating one of my debian-based servers recently and installing some new software using Debian's highly wonderful 'aptitude' utility.

And I kept getting this warning message: And I was getting it an awful lot. Perl was complaining about this whilst being invoked by the debian package management system. Here's the sort of output you'd get from perl:

# perl
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = ...
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Note: I've actually recreated this output after the fact so I'm not sure if the LANG setting shown above was what I saw originally. Typing the command
  locale
would give the a similar error.
  locale: Cannot set LC_CTYPE to default locale: No such file or directory
  locale: Cannot set LC_MESSAGES to default locale: No such file or directory
  locale: Cannot set LC_ALL to default locale: No such file or directory

It took a while to figure out the picture here. For a while I fumbled around with commands like locale, locale-def and read the man pages for locale, setlocale all the while descending further into a fog of confusion. It would be fair to say my mind grows weak at the thought of i18n, L10n and character encodings. But persist I did. Finally by some stroke of luck that I can't remember I came across the man page for

  locale-gen
The sun started shining again and things started to make sense between me and my Debian system once more.

So, what locale-gen says is this:

   This manual page documents briefly the locale-gen command.

   By  default,  the  locale  package  which provides the base support for
   localisation of libc-based programs does not contain  usable  localisa
   tion  files  for  every  supported language. This limitation has became
   necessary because of the substantial size of such files and  the  large
   number  of languages supported by libc. As a result, Debian uses a spe
   cial mechanism where we prepare the actual localisation  files  on  the
   target host and distribute only the templates for them.

   locale-gen is a program that reads the file /etc/locale.gen and invokes
   localedef for the chosen localisation profiles.  Run  locale-gen  after
   you have modified the /etc/locale.gen file.

That was certainly more promising. I had been fumbling around with localedef

  localedef --help
which prints the default paths used by localedef. These "default" paths were listed like this:
  locale path    : /usr/lib/locale:/usr/share/i18n

It wasn't terribly clear what all this meant until I started reading up on locale-gen. My /usr/lib/locale was empty or had been emptied, and /usr/share/i18n was packed to the gills with every lang/encoding template-thingumy-jig you could poke a stick at.

Next stop:

  man locale.gen
which said this:
   The  file /etc/locale.gen lists the locales that are to be generated by
   the locale-gen command.

   Each line is of the form:

   <locale> <charset>

   where <locale> is one of the locales given  in  /usr/share/i18n/locales
   and   <charset>  is   one   of   the   character   sets   listed   in
   /usr/share/i18n/charmaps

   The locale-gen command will generate all the locales, placing  them  in
   /usr/lib/locale.

First thing, I had to create /etc/locale.gen which I did with the following content:

en_AU UTF-8
en_AU ISO-8859-1
I'm using AU because I'm Australian. I've include ISO-8859-1 (also known as Latin-1) because when I first did this process I only included UTF-8 and I had funny characters and line break failures in man pages. It looks like my aging version of Debian had configured groff or whatever it used for manpages to output in Latin-1 and not UTF-8. (Note: when using the POSIX setting with no locales installed - see below - I didn't get this problem or any of the above warnings for that matter).

Then I ran

  locale-gen
which generated /usr/lib/locale/locale-archive . I'm not entirely sure this has solved the problem, but it seems my locale can now be set properly:
# locale
LANG=en_AU.UTF-8
LC_CTYPE="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_PAPER="en_AU.UTF-8"
LC_NAME="en_AU.UTF-8"
LC_ADDRESS="en_AU.UTF-8"
LC_TELEPHONE="en_AU.UTF-8"
LC_MEASUREMENT="en_AU.UTF-8"
LC_IDENTIFICATION="en_AU.UTF-8"
LC_ALL=

It seems that the locale error messages could have been removed by a much shorter route.

  export LC_ALL=POSIX
I also noticed that unsetting something like LANG which might have been set to a locale not installed in /usr/lib/locale also cleared up error messages.
  unset LANG
In both the above cases, "POSIX" is the value used for all LC and LANG settings. Despite this, it still seems to make sense to me, to install both utf-8 and latin-1 locales explicitly.

By the way, if you ever have annoying control characters in manpages and don't have the time to straighten the system out, try this:

  man some_man_page | col -b | less

Saturday, March 7, 2009

Living on the Commandline - The Beginning

Living on the Commandline - The Beginning

I first tried out linux in 2001. I think it was RedHat 7.1. The copy I had came with a magazine. I had brought it home after work and then proceeded to load it up on an old beige box - probably an old pentium II if I recall. Much later, probably in the early hours of the morning - something I still remember now to this day - I saw linux boot up for the first time; I distinctly remember loading up gnome for the first time and watching this foreign and exotic and distinctly non-windows graphical system load itself up on my screen.

I also remember turning the machine off at the switch. After all, that's what you did with dos right? Later, I learnt you had to do: "shutdown -h now" or something similar.

There was something seriously cool and special about doing this. This software was magic. It was free software; written by people who thought it was cool to build something like an alternative desktop system; or who thought it necessary to reverse engineer all the little utilities and foundational libraries that went into defining a unix system; or, most importantly, who thought it cool to actually build a new operating system (technically what is called the "linux kernel" here) which rock solidly ran all of the above.

It was like opening up a whole new universe. I've never looked back.

One of the powerful things about linux and unix in general is its commandline or shell. There is a philosophy and an ethos behind it, magically summed up in the 'Unix Programming Environment' and other such books.

I've struggled to clearly lay out why I think the commandline is so important and I suspect I shall fail here also. Anyone who runs a server (especially a non-Windows server) would understand. It is the power of knowing the name of the thing you want to access and being able to use it in ways that perhaps the original author did not conceive or intend; being able to combine it with other similar commands in a high-level program called a "shell script"; being able to invoke it at a future date in the early hours of the morning whilst you're safely tucked in bed... whatever. Knowing the "name" of a thing allows you to build and do your own things.

GUI (graphical user interface) programs and the commandline don't necessarily compete or intersect - insofar as the GUI is used for desktop applications, that is. No one would want to run Excel or Illustrator in some piecemeal way from the commandline via a series of written commands (although they might have reason to run an excel-like application in a terminal where the shell normally lives). [And of course, Excel has it's own built-in "shell" of a sorts - visual basic for applications - which allows you to script excel actions.]

Nonetheless, having only graphical applications at your disposal is a bit like being confined to a padded cell; a pretty cell with shiny, different coloured walls and flashing lights; but, a cell all the same - constructed for your imprisonment. Having the command line - knowing the "names" of things - allows you to drop out of this confined space into a more open world where you can build almost anything you want.

A well designed gui of course is a great thing indeed; such a thing is unfairly likened to a padded cell. But a mediocre or poor gui... well, it doesn't bear mentioning. Perhaps the thing I object to, is using a gui for everything; that is a great weakness; it limits your capabilities; it reduces your ability to extend yourself into the world and fully control it. I need to add that for normal everyday users, this power is not needed; I'm referring more to people who use computers to run or build services and programs.

Well, I've ranted enough. But now that I've said that, I'm going to post some follow-ups on some of the things I've learnt to do with the commandline.

Wednesday, February 11, 2009

Javascript namespacing and packaging - Draft 1

Packaging and namespacing standard for javascript projects - Draft 1

Date: Tue Feb 10 19:03:38 EST 2009
Subject: Packaging and namespacing standard for javascript projects - Draft 1
From: Daniel Bush - dlb.id.au AT gmail.com

BACKGROUND

The following questions motivate this README file.
  • What is the best way to structure a javascript project?
  • How do you package it and handle versioning?
  • How do you prevent clashes in the "global namespace"?
  • In short: how do you create an eco-system of javascript libraries created by multiple authors/vendors with multiple versions which other authors can easily use and handle in a reliable, controlled way?
Motivations for this document:
  • http://yuiblog.com/blog/2006/06/01/global-domination/
  • http://yuiblog.com/blog/2007/06/12/module-pattern/
  • http://blog.web17.com.au/2009/02/namespaces-in-javascript-1.html
This draft is a first attempt. It is likely there may be major revisions or unresolved issues.

TERMINOLOGY

One way to understand the problems covered in this document is to clearly identify the consituent parts that play a role. These are:
Publisher
A person or organisation who creates javascript code as an application or as a library to be used by other javascript applications by other publishers or the same publisher.
Global Namespace (GN)
A global variable that publishers use to contain all projects they produce. A GN is a javascript object:
var $GN$ = {};
(The '$$' format is discussed further down this document.)
Foreign Global Namespace (FGN)
An FGN is a GN used by some other publisher, which the current publisher is referencing in one of their projects. In the following, we'll often just refer to "GN" for a project regardless of whether it is using another project or being used by another project.
Project
Has the following features:
  • exists as a set of files and subdirectories under a root directory
  • unminified/unserialised; project may be spread across several files and include comments and spacing for human readability as well as additional files that aren't executed.
  • is version controlled using a version control system (VCS)
  • defines/creates one place in the GN of the publisher eg
     $GN$.project1
     $GN$.area1.project1
     etc    
  • may have dependencies on other projects in the same GN or in FGN's.
  • may be used as a dependency (library) or standalone
  • is intended to be packaged - see 'Package' below
A project can be built out of other projects.
Dependency
A project which another project relies on for some of its functionality. Dependencies are usually packaged and as a result, represent a specific version or snapshot of the project. Dependencies may use the same GN or an FGN.
Dependency Chain
A tree representing the dependencies of a project. Here is an example:
    B1
   /
A--
   \
    C1--B2
In this diagram, A,B,C are projects. B1,C1,B2 are specific versions of the projects they represent. Note: Although B1 and B2 are potentially different versions of the same project, they both occupy the same location of GN for that project. The last version to be loaded will therefore occupy this position in the GN once the dependency chain has been fully loaded into the system.
Level 1 of the tree represents A's dependencies (B1 and C1). The dependencies of A's dependencies are called 2nd order dependencies of A and occupy level 2 of the tree (B2).
Note: 'A' may be tagged version in a VCS or an in-between development version. Either way, any given snapshot of A relies on specific versions of its dependencies.
Load Order
The order in which a project and its dependencies (and their dependencies etc) are loaded. Load order can be defined recursively. A project loads itself by first loading its dependencies in a specified order (see packaging) and then loading itself.Loading involves the process of defining the GN if it does not exist already, and then building the relevant part of the GN namespace that is defined by the project or dependency. Using the dependency chain example above, the appropriate load orders are:
B1 B2 C1 A
Or:
B2 C1 B1 A
Load order is affected by the order in which the packages are referenced using script tags in an html file.
Load Time
(Sometimes referred to as 'load order time') The time during which the project and its dependencies are loaded into the interpreter. Can be thought of as the initialisation phase of the project This is emphasised because it is during this phase that clashes with project global variables may occur.
Package / Packaging
When a project is "packaged" it becomes a package.Packages have the following features:
  • usually minified; comments and spacing of the original project code are reduced or removed
  • usually a single file (serialised)
  • usually represent a particular tagged version of the project (usually using a tag in the VCS).
  • may include dependencies
  • javascript files of the project have to be serialised in load order when creating the single package file
  • The version number is explicity added to the end of the file. Eg project1-0.2.js would be version 0.2 of project1.
Module
A module (also referred to as the "module pattern") is a pattern identified by Yahoo!. See: http://yuiblog.com/blog/2007/06/12/module-pattern/ . Modules can be used to construct a part of a GN or project at load time and encourage the building of projects outside of the global namespace.
Frameworks
Frameworks are large, overarching sets of projects or libraries. Examples are jQuery and Prototype. Frameworks tend to use their own special GN's eg jQuery uses 'jQuery'; or occupy really common GN's eg Prototype uses 'Event', 'Ajax' etc Frameworks are mostly exempt from this document.
If you are using one, it will probably be included at the top of the load order. Projects and dependencies in the rest of the load order can then use the framework. It is up to the publisher to make sure they use an appropriate version of the framework to fit the requirements of the project and its dependencies.

RECOMMENDATIONS

1) Referencing global variables

Do NOT reference global variables in yet-to-be-executed function eg an asynchronous event handler.This includes referencing the GN or part of the GN or any other global variable that is a shortcut to the GN or part of the GN.
Global variables should be accessed at load time and preferably with a local variable within the scope of a module.
Rationale:
You cannot guarantee that the same version of a project is accesible through the GN after load time, because another project/dependency may have overloaded it through their dependencies. For shortcuts, the situation can be exacerbated; several dependencies (projects) may use the same shortcut to reference completely different things. If these shortcuts are global these shortcuts will get corrupted.
Example:
  var project1 = $GN$.area1.project1;
  project1.Object1 = function(){...}
  var p = new project1.Object();  
In this example, 'project1' is a global variable shortcut to a GN which is set up and then used straight away. Note: the above example should not be used for projects which are likely to be used as dependencies themselves as it is polluting the global namespace. See next point.
Example - bad:
  var project1 = $GN$.area1.project1;
  function doSomethingLater() {
    ...
    var obj = new project1.Object1();
    ...
  }  
In this example, the 'doSomethingLater' function is not executed but references a global shortcut 'project1'. In an environment that has multiple dependencies from multiple authors, the 'project1' could be overwritten by another dependency at load time and is not guaranteed to be correct. Even if we don't use a shortcut, it is possible that $GN$.area1.project1 has been overwritten with a different version.

2) Using modules to build the GN and to reference other GN's

If your project is intended or likely to be used as a dependency (a library to some other project), then i) it should be constructed using a module (at load time) and ii) the GN's of its dependencies should be referenced inside this module. Shortcuts to such GN's should be created within the scope of the module at or near the top.
Rationale:
A dependency which has other dependencies, will reference them in its module that builds that dependency at load time thus ensuring that the dependency has kept a reference to the appropriate version .
Example:
$GN1$.project1 = function() {
  ...
  var project2 = $GN2$.area1.project2;
  ...
  ...
  ...
}();
In this example, project2 is a dependency of project1 and is referenced within the executed scope of the anonymous function. Assuming load order and packaging have been set up properly, this should ensure that project1 is using the appropriate version of project2.
Note: Use of this technique within the context of the load order may mitigate any clashes in the GN; but it still makes sense to keep GN's unique to clearly distinguish publishers.

3) GN naming scheme

Use double dollar sign to denote a GN. The string between the dollar signs should represent a domain name of the publisher with the dots replaced by underscores. eg $web17_com_au$ would represent the GN for the publisher who owns the web17.com.au domain name.
Rationale:
If there are a proliferation of publishers creating javascript projects and libraries that can be used by other publishers, the likelihood of the same GN being used by different publishers increases; a modified domain name will reduce this risk.
The dollar signs signify that the variable is a GN and is part of the packaging system rather than just another variable in a program.
It also encourages the use of shortcuts. The GN should not be interspersed throughout the code in the project. It should be referenced by a shortcut at the top of a module or project.

OTHER SUGGESTIONS

1) Starting a GN

To start a GN, do:
var $GN$ = $GN$ || {};
This statement should be outside of any function. You do not create FGN's. By definition, they have been created for you by the dependency.

2) Modules

A suggested module pattern:
$GN$.project1 = function() {
 var module={};
 var shortcut1 = $FGN1$.path.to.project.Object1;
 var shortcut2 = $FGN2$.path.to.project.Object2;
 ...

 // Private module members.
 var private_var1 = ...;

  ...

 // Public module members.

 module.Object1 = function(...) {...}
 module.function1 = function(...) {...}
 ...

 // Return 'module' to build $GN$.project1 namespace.
 return module;
}();

3) Extending modules - submodules

Suppose you have built the module in point 2). You can extend the module (maybe in a separate file) likeso:
$GN$.project1.area1 = function() {
 ...
}();
Notes:
  • this file would need to come after the first file defining $GN$.project1 at load time
  • A new module is being created at project1.area1 - ie a submodule; this module clearly cannot see any private data in the parent module.
  • care needs to be taken that area1 doesn't overwrite a namesake defined in the project1 module1.
$GN$.project1 = function() {
  ...
}
$GN$.project1.Object2 = function() {
  var shortcut1 = $FGN1$.project2;  // Not so good.
  ...
}
In this example, the project1 module is augmented with a new object not a submodule.An attempt is made to create a shortcut within Object2. Unfortunately, this object can be instantiated at a later time when $FGN1$.project2 might have been overwritten with a different version. Granted, this is probably not that likely.

4) Layout of project

The following might represent the file structure for a project:
/
/ext
/ext/projectA-0.2.js
/ext/projectB-1.1.2.js
/globals.js
...
/module1
/module1/module1.js
/module1/submodule1.js
/module1/submodule2.js
...
/module2/module2.js
...
  • The above layout uses a directory called 'ext' to store dependencies - ie other projects are used by this project.
  • The dependencies are packaged with their version numbers displayed so it obvious to the maintainer.
  • The globals.js file sets up the $GN$ for the project including the relevant part of the $GN# which this project will handle. Eg
    var $GN$ = $GN$ || {};
    $GN$.module1={};  // Initialize the module for this project.    
  • A large project might create several modules and submodules; it may make sense to provide a subdirectory for each module and its submodules.

Sunday, February 8, 2009

Namespaces in javascript 1

Here are some of the issues I want to cover - not just in this post but maybe in several including this one:
  • What is the best way to structure a javascript project?
  • How do you package it and handle versioning?
  • How do you prevent clashes in the "global namespace"?
  • In short: how do you create an eco-system of javascript libraries created by multiple authors/vendors with multiple versions which other authors can easily use and handle in a reliable, controlled way?

The Namespace / Global Problem

It's easy to create small useful components or helper libraries in javascript which you could publish, say to github.com, and have other people use. But, if enough of this happens and you don't pay attention to how the global namespace[1] is used then you will eventually get some namespace clashes. For my part, I'm interested in how to safely namespace javascript components written by me or other people.

Creating a simple namespace

First off, easiest way to create a global namespace (ie a global variable that acts as a namespace) is to do something like:
var NS1={};
between the script tags on your web page or in a .js file referenced by your webpage.Then, you can proceed to use NS1 to namespace any other object constructors, functions, variables you care to use.
NS1.Object1 = function() {...}
var o = new NS1.Object1();
A popular javascript library like prototype already stakes its claim to globalisation by taking some of the more obvious global variable names eg 'Ajax', 'Event' etc JQuery is more cautious and puts everything in a 'jQuery' namespace. Both libraries use '$' as a convenience global variable.In:
Douglas Crockford and Yahoo! discuss suggested practices. If you're a company called Yahoo, then you use a global variable YAHOO (which I'll refer to as a global namespace[1]). Douglas suggests using all-caps to make it more obvious that this global variable has a special purpose - to be a global namespace.The module pattern in the second link takes it one step further and suggests a way to build up a group of both public and private variables and functions (a "module") which are built within the scope of an anonymous function. The object returned by this anonymous function is called a "module" and is referenced by a name within the global namespace - in this case "module1":
YAHOO.module1 = function() {
  var private_var1 = .... ;
  ...
  return {
    Object1: function() { ... }
  };
  ...
}();
The returned object or module will have public variables and functions - in the example above, Object1 is a public constructor function of the returned anonymous object. This extends the YAHOO.module1 namespace to YAHOO.module1.Object1.
Which we can use like this:
var o = new YAHOO.module1.Object1();
It is just as easy to have private functions, objects and variables simply by using the 'var' statement within the anonymous function.

Shortcuts for namespaces

It can get tiresome having to reference an object or field by its fully qualified namespaced name.We can create a shortcut like this:
var O = YAHOO.module1.Object1
and then use it
var o = new O()
This is great except where "O" happens to be global.You might be tempted to set O globally, then just casually reference it inside your application:
var O = YAHOO.module1.Object1;
var NS1.SomeObject2 = function() {
  this.doSomething = function() {
  ...
  var o = new O();
  ...
  }
}
In the above, NS1 is a global namespace for some publisher of javascript widgets.The problem is that NS1 has used "O" as a global variable shortcut for a library that it is using from the YAHOO global namespace (it could just as easily be some other object in the same namespace).What happens if NS2 comes along and builds a javascript widget that relies on NS1's "SomeObject2"?
Nothing much except if NS2 in turn decides to use "O" as its global shortcut for some other object that it is using.Bear in mind, the application that NS2 is building will load on the page first by loading NS1 which in turn will first load the YAHOO module1 and its object.So the load order is YAHOO, NS1 and NS2. The global "O" will get set first by NS1 and then overwritten by NS2.
Then, when NS2 runs and instantiates the object in NS1, "O" no longer means what NS1 intended. This of course illustrates the problem with using global variables in general.The moral of the story is to set your shortcuts within the scope of your object.
More precisely, it's ok to use a shortcut for your namespace if it gets used then and there; if it gets referenced in a yet-to-be-executed scope (eg some function that gets called later) then we open ourselves up to potential, nasty, hard-to-debug problems especially where multiple vendors/authors are being used.
The module pattern above encourages non-global shortcuts. As with everything else in our module, the anonymous function houses both the stuff of the module and the shortcuts it uses.

[1] - the term "global namespace" can get used with 2 different meanings in this document; (1) the actual global "space" in which global variable names exist; and (2) a given global variable acting as a namespace for given author/vendor.