"Jeffrey Snover [MSFT]" <firstname.lastname@example.org> wrote in message
> This blog explains our namespaces and their usages. It was extensively
> reviewed with the .NET team so while it may or may not be good - it was
> certainly very thoughtful.
OK. So, paraphrasing the area of my interest a bit and exploring a couple of
things NOT covered in the blog entry yet -
Microsoft uses Microsoft.PowerShell.Commands as the namespace for both
specific cmdlets and specific providers, because those are both about
commands: providers tend to extend the reach of commands directly.
A development group such as the PowerShell Community Extensions project
could then come along and to use a similar pattern so people familiar with
Microsoft's namespace would be able to understand the extensions namespace
structure. From what I see, the following look logical; any corrections?
(1) Assuming that the OEM/Project identification namespace is going to be
PsCx.PowerShell, the root namespace for PowerShell cmdlets and providers
would be PsCx.PowerShell.Commands.
(2) Using the very uniform current scheme for Microsoft's command names, a
development project would use Verb + Noun + "Command" for specific cmdlets.
For example, a New-Process cmdlet would have the fully qualified classname
(3) Analogously, new providers would use Storetype + "Provider"; for
example, an XML document provider would be