Best practices for creating a namespace for an extension to another company's product?

Question

I typically follow the Company.(Product|Technology)[.Feature][.Subnamespace] pattern encouraged by Microsoft: http://msdn.microsoft.com/en-us/library/ms229026 when naming class libraries.

I'm wondering what convention to use when naming a class library that contains mostly code wrapped around another company's product. My specific case is a set of Exchange Server extensions which will wrap the Exchange Web Services API with some helper functionality.

Normally, I would use the company name as a subnamespace, such as:

TimsCompany.Communication // contains generic communication code
TimsCompany.Communication.Microsoft // contains Microsoft specific code

But since this library's whole purpose is to extend Microsoft Exchange, I was thinking along the lines of:

TimsCompany.MicrosoftExtensions.Exchange

OR

TimsCompany.Microsoft.Exchange.Extensions

OR

TimsCompany.Microsoft.Exchange

ETC

Published standards? Best practices?

EDIT: One precedent that I have dug up is Microsoft's data provider for Oracle which uses the System.Data.OracleClient namespace: http://msdn.microsoft.com/en-us/library/system.data.oracleclient.aspx

Note that Microsoft has deprecated this library, but not for naming reasons.

This leads me to wonder if vendor-specific functionality might still belong under another more generic namespace (as in the case of System.Data).

It also leads to the discussion of fewer, larger class libraries versus many smaller ones, but that's a different topic.

Answer 1

Well, I would say that you have the following:

Company: TimsCompany
Product: ExchangeExtensions

So, I would use:

TimsCompany.ExchangeExtensions or
TimsCompany.Communication.ExchangeExtensions.

---

I don't see any particular reason to include "Microsoft" in the namespace, since "Exchange" is pretty unambiguous.

However, if pressed to add it, I would just say that this is the scenario:

Company: TimsCompany
Product: MicrosoftExchangeExtensions

So:

TimsCompany.MicrosoftExchangeExtensions or
TimsCompany.Communication.MicrosoftExchangeExtensions.

That last one is pretty verbose, tho. Not my recommendation.