On Thu, May 29, 2003 at 07:51:45PM -0700, Darren Duncan wrote:
> 
> So, my first questions are these: 1. Would a DOM-for-SQL be useful in its
> own right to other module developers, and therefore grow beyond its
> previous intention of being "part of just one framework";

Er, perhaps :-)

> 2. What should this new module be called?

> Rosetta::Schema
> Rosetta::DOM
> Rosetta::Dictionary
> SQL::DOM
> SQL::Parsed
> SQL::Dictionary
> Class::SQL
> Class::AbstractSQL
> Class::ParsedSQL
> Class::SQLDOM
> 
> Now, some of the issues I need to keep in mind are:
> 1. My class has nothing to do with XML, although they could be serialized
> into XML, so I am wondering whether "DOM" implies XML and therefore I
> shouldn't use it.

DOM shouldn't imply XML. But you could drop the D and expand the OM into
SQL::ObjectModel, or Class::SQLObjectModel, for example.

> 2. My class is meant to also be usable with databases that don't
> understand SQL natively (such as older ones), so would having "SQL" in the
> name be a problem.  I suspect it may not.  Also, is "SQL" trademarked?

It's not trademarked. I'd say the benefits of including SQL in the
name outweigh any limitation it may imply.

> 3. Since Rosetta as a whole depends so much on these modules (despite the
> effort to make them usable on their own), would it just be better to leave
> them named "Rosetta::*" but still distribute them separately?  What would
> be the most descriptive of what they do?  Or could it be said that these
> "Schema" modules in fact *are* Rosetta and everything else is an extension
> to them?

Frameworks can be intimidating to use. Requiring a significant 'buy in'.
I think you'd gain more users overall by breaking it up (all else being equal).

Also I think you'll need to address Rosetta::Locale:: in a similar way.
Give it a new lease of life as an independantly useful set of modules.
(And you might be surprised to find that they become more widely used than
the other parts as it addresses a more common problem.)


> A question: 4. Would a comprehensive intermediate SQL object be useful to
> writers of a lot of these modules, so they can more quickly support the
> parsing or generation of more complex SQL, and improve their works?

[EMAIL PROTECTED] is probably a better place to ask that.


Tim.

Reply via email to