commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Stanley <mstan...@mstanley.net>
Subject Re: [xmlio] Naming
Date Sat, 09 Oct 2004 18:34:59 GMT
By doing this, I believe there will be far less confusion for people 
browsing the commons proper and sandbox catalogs.

Run with [xmlutil]  I think the shoe fits :-)

- Mike

Mike Stanley wrote:

> I don't think they should be split.  If it is a library for helping 
> the input/output of XML why separate these into separate projects.  
> Lets not get carried away with small functional libraries.  There 
> should be a limit to the size, purpose.   I mean there has to come a 
> point where the overhead of a new subproject isn't worth the benefit 
> of the logical separation of otherwise related classes.
>
> If the library is
> 1) not a parser
> 2) not an XML marshaller
> 3) not an xml ingester (like digester)
> 4) not a bean serializer
>
> but rather a utility for inputing and outputting XML documents 
> (augmenting SAX with callbacks).
>
> Then it needs a name that reflects that.  I believe the only name I've 
> heard so far that doesn't make me think of one of the above is 
> "xmlutil", but then again that will open up the project to be the home 
> of other xml utility classes beyond input and output.  Is this a goal 
> of the project?  Perhaps it should be.
>
> I suggest taking the name "xmlutil" and growing this to an XML utility 
> library - in the same family as beanutil, collection, lang, etc.  
> Input and output of XML documents is just one utility that can be 
> offered.
> - Mike
>
> Gary Gregory wrote:
>
>> [xml-in] and [xml-out]
>>
>> ?
>>
>> Gary
>>
>>  
>>
>>> -----Original Message-----
>>> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
>>> Sent: Saturday, October 09, 2004 04:20
>>> To: Jakarta Commons Developers List
>>> Subject: Re: [xmlio] Naming
>>>
>>> Please see the commons charter on naming. Paraphrasing it says that
>>>   
>>
>> "names
>>  
>>
>>> should be boring and functional, not clever". jazz is clever ;-(  The
>>> reasoning is to remove one more barrier to adopting the component.
>>>   
>>
>> (Note
>>  
>>
>>> that not every commons component follows the rule, betwixt being a
>>>   
>>
>> good
>>  
>>
>>> example)
>>>
>>> maybe [sax] for input? (commons-sax)
>>> or [fromsax] - (commons-fromsax)
>>> maybe [toxml] for output? (commons-toxml)
>>> or [tosax]? (commons-tosax)
>>>
>>> It depends on whether you want to scope/limit yourself to just sax.
>>>
>>> Should you split? It depends on whether people who use one half are
>>>   
>>
>> likely
>>  
>>
>>> to use the other really.
>>>
>>> Stephen
>>>
>>> ----- Original Message -----
>>> From: "Daniel Florey" <daniel.florey@web.de>
>>>   
>>>
>>>> After doing the xmlio google thing I agree that this name is really
>>>>     
>>>
>> used
>>  
>>
>>> in
>>>   
>>>
>>>> so many projects that it would be worth to find another one even if
>>>>     
>>>
>> I
>>  
>>
>>> like
>>>   
>>>
>>>> it.
>>>> As 'xmlio' consists of two parts (importer / exporter) I would
>>>>     
>>>
>> recommend
>>  
>>
>>>> separating them into two tiny components in order to increase
>>>>     
>>>
>>> reusability.
>>>   
>>>
>>>> My favourite name for the importer (sax augmentation) would be
>>>>     
>>>
>> 'jazz'.
>>  
>>
>>> As
>>>   
>>>
>>>> you need a sax to play jazz... (Or is it 'just augmented super
>>>>     
>>>
>> sax'??)
>>  
>>
>>>> The exporter could be simply called XMLWriter as this is what it
>>>>     
>>>
>> does.
>>  
>>
>>>> Finally I'd like to say that I don't think Digester and xmlio are
>>>>     
>>>
>> direct
>>  
>>
>>>> competitors as they are very different: xmlio is a simple sax
>>>>     
>>>
>> extension
>>  
>>
>>> but
>>>   
>>>
>>>> has nothing to do with mapping xml to java objects.
>>>> So I don't think we get trouble here.
>>>>
>>>> Regards,
>>>> Daniel
>>>>     
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>   
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>  
>>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message