On 8 Dec 2009, at 15:10, Dan Allen wrote: > Oops, I was getting my URLs and URNs mixed up. Thanks for the correction. > > I'm torn. The fewer characters do make it easier for my brain to remember and also gives an indication that the namespace is somehow different. I don't think it would hurt as an alternative syntax.

to introduce this variance, and thus one more thing to explain. > > Another option would be to allow users to alias one namespace to another so they can control how covenient it is. Just brainstorming. Yeah, this seems like a better option to me :-)

I would like to know *why* this being proposed as well.

On 8 Dec 2009, at 17:55, David Geary wrote: > And they have no idea why the have to specify such a long, ugly, and difficult to remember prefix to the directory when all they want to do is specify the directory. Agreed, I don't think for the composite components we made the best choice for URI schema, IMO it should have been more like xmlns:pete="composite:components/pete"

On Dec 9, 2009, at 5:11 AM, Pete Muir wrote: > Agreed, I don't think for the composite components we made the best choice > for URI schema, IMO it should have been more like > > xmlns:pete="composite:components/pete" > > - the big difference to the original proposal is that we are still within > the URI scheme guidelines because we use a scheme name. By defining our own > scheme, we are then free to choose how the "hierarchical part" looks. > Arguably we could go for a less generic scheme name like "faces" or "jsf": > > xmlns:pete="faces:composite:components/pete" > > which is a bit longer but more generic... > I like this approach. Of the two, part of me thinks the second might be the better choice, as it gives us a bit more flexibility to add things under the faces scheme, thus kind of grouping things together, but another part of me wonders if we'd ever want to do that, given the context of the discussion (YAGNI ;). However, it's only 6 characters (or 4 for "jsf:"), so I don't see the harm in the slightly longer proposal.

Jason Lee, SCJP President, Oklahoma City Java Users Group Senior Java Developer, Sun Microsystems http://blogs.steeplesoft.com

On Dec 9, 2009, at 5:11 AM, Pete Muir wrote: > Agreed, I don't think for the composite components we made the best > choice for URI schema, IMO it should have been more like > > xmlns:pete="composite:components/pete" > > - the big difference to the original proposal is that we are still > within the URI scheme guidelines because we use a scheme name. By > defining our own scheme, we are then free to choose how the > "hierarchical part" looks. Arguably we could go for a less generic > scheme name like "faces" or "jsf": > > xmlns:pete="faces:composite:components/pete" > > which is a bit longer but more generic... I like this approach. Of the two, part of me thinks the second might be the better choice, as it gives us a bit more flexibility to add things under the faces scheme, thus kind of grouping things together, but another part of me wonders if we'd ever want to do that, given the context of the discussion (YAGNI ;). However, it's only 6 characters (or 4 for "jsf:"), so I don't see the harm in the slightly longer proposal.

I like both of these suggestions. Less is more. > Further, in the interest of brevity, why say "composite"? Why not match the > implicit EL object and just say "cc"? > > Thus: > > xmlns:jim="jsf:cc:jim" > > Isn't that just as clear to someone who already knows what #{cc} is? > > Concerned that it's too cryptic? Look at the first part of that phrase. > Anyone think that the XML standards guys should have called it xmlnamespace > instead of xmlns? > > Shorter is almost always better, especially for frequently typed > boilerplate. > > Jim >

On 12/9/09 7:07 AM, Jason Lee wrote: > On Dec 9, 2009, at 5:11 AM, Pete Muir wrote: >> Agreed, I don't think for the composite components we made the best >> choice for URI schema, IMO it should have been more like >> >> xmlns:pete="composite:components/pete" >> >> - the big difference to the original proposal is that we are still >> within the URI scheme guidelines because we use a scheme name. By >> defining our own scheme, we are then free to choose how the >> "hierarchical part" looks. Arguably we could go for a less generic >> scheme name like "faces" or "jsf": >> >> xmlns:pete="faces:composite:components/pete" >> >> which is a bit longer but more generic... > > I like this approach. Of the two, part of me thinks the second might be > the better choice, as it gives us a bit more flexibility to add things > under the faces scheme, thus kind of grouping things together, but > another part of me wonders if we'd ever want to do that, given the > context of the discussion (YAGNI ;). However, it's only 6 characters (or > 4 for "jsf:"), so I don't see the harm in the slightly longer proposal. I would prefer jsf:composite:jim for components under resources/jim, and jsf:composite:comp/jim for components under resources/comp/jim. Two characters might not seem like a lot, but why not use jsf instead of faces if it signifies the same thing to users and is shorter? (We already use "jsf" in the Ajax library.) Further, in the interest of brevity, why say "composite"? Why not match the implicit EL object and just say "cc"? Thus: xmlns:jim="jsf:cc:jim" Isn't that just as clear to someone who already knows what #{cc} is? Concerned that it's too cryptic? Look at the first part of that phrase. Anyone think that the XML standards guys should have called it xmlnamespace instead of xmlns? Shorter is almost always better, especially for frequently typed boilerplate. Jim

Just to clarify, the "components" directory is not required under resources. The developer has the option of doing: jcf:cc:acme which resolves to /resources/acme Since cc stands for composite components, some people may see the "components" directory as redundant (as we cited in earlier examples in the thread). I'm just stating a fact for clarification. -Dan On Fri, Dec 11, 2009 at 10:03 AM, Roger Kitain <Roger.Kitain(a)sun.com&gt;wrote: > "cc" is fine since it matches the EL expression (consistency). > I also think "jsf" is fine especially since "jsf" is used in the core (f) > and html (h) > namespaces. > > -roger > > > Jim Driscoll wrote: > >> >> >> On 12/9/09 7:07 AM, Jason Lee wrote: >> >>> On Dec 9, 2009, at 5:11 AM, Pete Muir wrote: >>> >>>> Agreed, I don't think for the composite components we made the best >>>> choice for URI schema, IMO it should have been more like >>>> >>>> xmlns:pete="composite:components/pete" >>>> >>>> - the big difference to the original proposal is that we are still >>>> within the URI scheme guidelines because we use a scheme name. By >>>> defining our own scheme, we are then free to choose how the >>>> "hierarchical part" looks. Arguably we could go for a less generic >>>> scheme name like "faces" or "jsf": >>>> >>>> xmlns:pete="faces:composite:components/pete" >>>> >>>> which is a bit longer but more generic... >>>> >>> >>> I like this approach. Of the two, part of me thinks the second might be >>> the better choice, as it gives us a bit more flexibility to add things >>> under the faces scheme, thus kind of grouping things together, but >>> another part of me wonders if we'd ever want to do that, given the >>> context of the discussion (YAGNI ;). However, it's only 6 characters (or >>> 4 for "jsf:"), so I don't see the harm in the slightly longer proposal. >>> >> >> >> I would prefer jsf:composite:jim for components under resources/jim, and >> jsf:composite:comp/jim for components under resources/comp/jim. Two >> characters might not seem like a lot, but why not use jsf instead of faces >> if it signifies the same thing to users and is shorter? (We already use >> "jsf" in the Ajax library.) >> >> Further, in the interest of brevity, why say "composite"? Why not match >> the implicit EL object and just say "cc"? >> >> Thus: >> >> xmlns:jim="jsf:cc:jim" >> >> Isn't that just as clear to someone who already knows what #{cc} is? >> >> Concerned that it's too cryptic? Look at the first part of that phrase. >> Anyone think that the XML standards guys should have called it xmlnamespace >> instead of xmlns? >> >> Shorter is almost always better, especially for frequently typed >> boilerplate. >> >> Jim >> > > -- 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

On Fri, Dec 11, 2009 at 11:45 AM, David Geary <clarity.training(a)gmail.com&gt;wrote: > Yup, understood, thanks for the clarification, Dan. > > btw, it seems to me that we really don't need the jsf prefix either. After > all, it's only used in JSF applications, so I'd just prefer something like > cc:acme, which of course, ala Dan's clarification really means cc:whatever. > > I suppose one could argue that we should have it because we have it in our > other namespaces, but we're not using java.sun.com, which we also have in > the other namespaces, so why not just simplify as much as possible and say > cc:whatever? > 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).

One other point to think about. The reason we are sticking with a valid XML namespace syntax is because, if you recall, the goal in the future is to recognize the view template as a pure XML document that can leverage all of the great XML tooling that is already out there w/o any special plugins. We can have an XSD generated automatically (or hand written) and then you get tag completion on your new, shiny composite components. If we abandon XML rules, we jeopordize that vision. (proposal for all that is pending...somewhere in my 1000 things to do)

-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

> One other point to think about. The reason we are sticking with a valid

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).

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.

At any rate, the main issue here is consistency with the rest of Java EE -- we should be careful here.

> > 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. > Heck, while we are here, why don't we just do: xmlns:f="jsf:core" xmlns:h="jsf:html" xmlns:ui="jsf:ui" I'm trying to think if there are problems with doing that, but we can associate the schema with these shorter names. The real benefit of using a full-blown URI is that you can avoid conflicts w/ other namespace providers. But since we are JSF (there can be only one JSF, evil laugh) then why not?

-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

Hi guys, very useful discussion. I like a) the most, and my +10 for the URN-version for the core taglibs as well. Beautiful! I think it actually has to be a), so that we are inline with our specifications for the core taglibs, and that we don´t pollute the namespace too much.

I´m sitting right here imaginating there comes the day were I don`t have to tell developers to copy out the header "from some other file".

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).