[jsr-314-open] [JSF 2.1 NEW] composite component namespace simplification

Dan Allen dan.j.allen at gmail.com
Fri Dec 11 13:49:25 EST 2009


On Fri, Dec 11, 2009 at 1:25 PM, Jim Driscoll <Jim.Driscoll at sun.com> wrote:

>
>
> On 12/11/09 9:09 AM, Dan Allen wrote:
>
>>
>> Just to throw in another option, we could do jsfcc. That way, we qualify
>> but still cut another character.
>>
>> Perhaps we need a vote.
>>
>> a) jsf:cc:whatevername
>> b) cc:whatevername
>> c) jsfcc:whatevername
>>
>> I vote for (c).
>>
>
> I prefer (a), if we expect that there will be other URNs that we define.
>  Do we expect that to happen?
>
> If not, then I have a question about URNs: will the user be able to be
> define others? (Sorry, my XML knowledge is woefully inadequate).


Sure. Any custom component library could standardize on a URN rather than a
full-blown URI. Whether it be us in the future or just a convention by
users.


> If the user can define new ones, then I'd again prefer a), otherwise, b).
>  I'd prefer to have either (a) or (b), since it matches existing
> abbreviations - jsf, and cc.  Having a new one, jsfcc, adds to the semantic
> load of learning the API, which, I think, outweighs the advantage of losing
> the extra character.
>

My second choice is (a), so if I lose on (c), I'll be happy with (a) too. I
think that (b) is just too vague.

-Dan

-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20091211/43a17de8/attachment.html 


More information about the jsr-314-open-mirror mailing list