<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div><div>On May 29, 2008, at 10:05 AM, John P. A. Verhaeg wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"> <div bgcolor="#ffffff" text="#000000"> 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:<br> <ol> <li>Define the URI's in a separate class or interface, or</li> <ul> <li>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).</li> <li>Con: It is not necessarily an intuitive place for developers to look when working with a particular API.</li> <li>Pro: This could provide a "default" location to store other constants that we determine we need during the course of development.</li></ul></ol></div></blockquote>Pro: There maybe better handle different families of namespaces (e.g., "JCR1", "JCR2", "XSD", "DNA", etc.).</div><div>Pro: The pattern is extensible and can be copied by connectors, sequencers, etc.<br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"><ol start="2"> <li>Define them in an existing class, such as the org.jboss.dna.spi.graph.NamespaceRegistry interface.</li> <ul> <li>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.</li> <li>Con: There may not always be an appropriate class to define such constants (or methods).</li> <li>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.<br> </li> </ul> </ol> where by "define", we could either:<br> <ol> <li>Provide constants for the URI's (e.g., <b><tt>public static final String JCR_URI = <a class="moz-txt-link-rfc2396E" href="http://www.jcp.org/jcr/1.0">"http://www.jcp.org/jcr/1.0"</a></tt></b>), or</li> <ul> <li>Pro: The value of the URI would be readily apparent within the JavaDocs (via <b><tt>@value</tt></b>).<br> </li> </ul> <li>Provide methods to return the URI's (e.g., similar to <b><tt>NamespaceRegistry.getDefaultNamespaceUri()</tt></b>).</li> <ul> <li>Pro: This may provide more consistency with other methods (such as the example above).</li> <li>Con: Not sure if a method would be the intuitive place to look for a constant value.</li></ul></ol></div></blockquote></div><div>Con: Could be changed/overridden by implementations; there seems to be no benefit to this.</div><div>Con: The "NamespaceRegistry.getDefaultNamespace()" method does not return a constant value - the method returns whatever namespace URI is <i>at that moment</i> defined to have a zero-length prefix. These well-known namespace URIs are really constants.</div><div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"> 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.</div></blockquote><div><br></div><div>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?</div><div><br></div><div>Thoughts?</div><div><br></div><div>BR, Randall</div><div><br></div></div><br></div></div></body></html>