I agree with Micah. Moreover, adding "org.apache" does not disambiguate
anything; "arrow" should be the reserved namespace for canonical
(extension) types.
Neal
On Wed, Aug 24, 2022 at 12:31 PM Micah Kornfield <emkornfi...@gmail.com>
wrote:
> Sorry for beling late. I'm -0.5 on "org.apache.arrow." given people
> previously raising naming concerns about having "apache" and "arrow"
> coupled together. I think just "arrow" makes sense here.
>
> I also am not sure about relaxing the 2 language requirement for simple
> implementations, but feel less strongly about this.
>
> On Wed, Aug 24, 2022 at 9:25 AM Pradeep Gollakota
> <pgollak...@google.com.invalid> wrote:
>
> > +1 (non-binding) With a slight preference for well defined names starting
> > with "arrow." instead of "org.apache.arrow."
> >
> > On Wed, Aug 24, 2022 at 12:16 PM David Li <lidav...@apache.org> wrote:
> >
> > > +1 (binding)
> > >
> > > Just to check, these rules will presumably be committed into the
> > > documentation as well?
> > >
> > > On Wed, Aug 24, 2022, at 11:24, Antoine Pitrou wrote:
> > > > Hello,
> > > >
> > > > I would like to propose we vote for the following set of rules for
> > > > registering well-known ("canonical") extension types.
> > > >
> > > >
> > > > * Canonical extension types are described and maintained in a
> separate
> > > > document under the format specifications directory:
> > > > https://github.com/apache/arrow/tree/master/docs/source/format (note
> > > > this gets turned into HTML docs by Sphinx =>
> > > > https://arrow.apache.org/docs/index.html)
> > > >
> > > > * Each canonical extension type requires a separate discussion and
> vote
> > > > on the mailing-list
> > > >
> > > > * The specification text to be added *must* follow these requirements
> > > >
> > > > 1) It *must* have a well-defined name starting with
> > > "org.apache.arrow."
> > > > 2) Its parameters, if any, *must* be described in the proposal
> > > > 3) Its serialization *must* be described in the proposal and
> should
> > > > not require unduly work or unusual software dependencies (for
> example,
> > a
> > > > trivial custom text format or JSON would be acceptable)
> > > > 4) Its expected semantics *should* be described as well and any
> > > > potential ambiguities or pain points addressed or at least mentioned
> > > >
> > > > * The extension type *should* have one implementation submitted;
> > > > preferably two if non-trivial (for example if parameterized)
> > > >
> > > >
> > > > The vote will be open for at least 72 hours.
> > > >
> > > > [ ] +1 Accept this proposal
> > > > [ ] +0
> > > > [ ] -1 Do not accept this proposal because...
> > > >
> > > >
> > > > Regards
> > > >
> > > > Antoine.
> > >
> >
> >
> > --
> > Pradeep
> >
>
