[dna-dev] Well-known namespaces

[Randall Hauch]

On May 29, 2008, at 10:05 AM, John P. A. Verhaeg wrote:

> While working on the XML sequencer, I determined that I will need  
> access (via the SPI project) to some "well-known" namespace URI's in  
> order to build node names, types, and path segments correctly.   
> There are a few options here:
> Define the URI's in a separate class or interface, or
> Con: The need for an "artificial" class just to hold constants  
> always feels a little non-OO (although I guess that argument could  
> be made for anything that's considered globally accessible).
> Con: It is not necessarily an intuitive place for developers to look  
> when working with a particular API.
> Pro: This could provide a "default" location to store other  
> constants that we determine we need during the course of development.
Pro: There maybe better handle different families of namespaces (e.g.,  
"JCR1", "JCR2", "XSD", "DNA", etc.).
Pro: The pattern is extensible and can be copied by connectors,  
sequencers, etc.
> Define them in an existing class, such as the  
> org.jboss.dna.spi.graph.NamespaceRegistry interface.
> Pro: The constants (or methods) would be defined near the methods  
> with which you would most likely use them, potentially making it  
> easier to know where to look for them.
> Con: There may not always be an appropriate class to define such  
> constants (or methods).
> Con: When the constants are appropriate for use with multiple  
> classes, it may be difficult or somewhat arbitrary deciding in which  
> class they should be defined.
> where by "define", we could either:
> Provide constants for the URI's (e.g., public static final String  
> JCR_URI = "http://www.jcp.org/jcr/1.0"), or
> Pro: The value of the URI would be readily apparent within the  
> JavaDocs (via @value).
> Provide methods to return the URI's (e.g., similar to  
> NamespaceRegistry.getDefaultNamespaceUri()).
> Pro: This may provide more consistency with other methods (such as  
> the example above).
> Con: Not sure if a method would be the intuitive place to look for a  
> constant value.

Con:  Could be changed/overridden by implementations; there seems to  
be no benefit to this.
Con:  The "NamespaceRegistry.getDefaultNamespace()" method does not  
return a constant value - the method returns whatever namespace URI is  
at that moment defined to have a zero-length prefix.  These well-known  
namespace URIs are really constants.

> I don't really have a religion regarding this one way or the other.   
> I just want to establish a pattern up front that everyone is  
> comfortable with, and so I can put as little thought as possible  
> towards this in the future.

Really, if we're just talking about the "standard" namespaces (e.g.,  
"jcr", "nt", "mix") and any DNA namespaces, then really these have to  
be defined by the sequencer's node type definitions.  Maybe the  
sequencers should just expect the standard namespaces to be registered  
already?

Thoughts?

BR, Randall


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/dna-dev/attachments/20080529/27ea919b/attachment.html