Hello! We can just discuss the impact here in the mailing list and make a decision by consensus. Sometimes for major changes, we do a more formal VOTE thread -- this might be one of those cases.
What would happen if we were to say that ".MyRecord" was valid in the next major version of Avro? Some SDKs used to accept this in the past and were made more strict, causing working examples to break? That is really unfortunate. On the other hand, if we generate Java code today and map packages 1:1 to namespaces... we still won't be able to mix namespaced (in a package) and unnamespaced (unpackaged) generated code. Would we just mangle the default namespace to "default$" or ... ? A configuration option for the SpecificCompiler in Java? Either way, it would be great if we didn't leave this point vague in the spec! There's always the possibility to allow language SDKs to deviate from the spec -- if e.g. python or Java has a "setValidateUnqualifiedNamespace(boolean)" method, we can leave it up to the user whether or not to follow the strict spec. We already do this with validating defaults in Java, for example. It might take a bit of thought, but if we can find some elegant way to make this work I don't see why we wouldn't make specification changes! Ryan On Thu, Aug 25, 2022 at 7:31 PM Brennan Vincent <[email protected]> wrote: > > That is a fair point also. > > Anyway, since I'm not an Apache project member, I'm not quite sure what > is the best way to move forward here. Is there a formal process for proposing > changes to the spec and reaching a consensus? > > Thanks > Brennan > > On 2022-08-25 01:36, Oscar Westra van Holthe - Kind wrote: > > Hi all, > > > > Allowing references to the null namespace from within another namespace > > gives schema authors more options. > > > > But if you're using namespaces at all, there must be a reason for it. As a > > schema author, you've made the decision to group your schemata. > > > > To make this decision from schema authors more visible, I'd opt to choose > > the Java route and in that case force all schemata to belong to a group. > > I.e., explicitly disallow identifiers to start with a dot (and disallow > > references to the null namespace from within another namespace). > > > > > > Kind regards, > > Oscar > > > > -- > > Oscar Westra van Holthe - Kind <[email protected]> > > > > Op wo 24 aug. 2022 14:42 schreef Ryan Skraba <[email protected]>: > > > >> Hello! There is definitely an ambiguity here caused by inheriting > >> namespaces. > >> > >> The obvious takeaway is to use a namespace with all of your named > >> schemas. As a best practice, that avoids the problem of mixing > >> schemas with and without namespaces, and it's probably this techniq > >> > >> This same problem occurs in Java classes, where you can have a class > >> in the default package (without a package name), but it's an error to > >> import it into other packages. > >> > >> The ".MyRecord" notation might be the right way to clarify this, but > >> we can also go the Java route (i.e. you can't mix namespaced schema > >> and non-namespaced schemas). What do you think? > >> > >> Best regards, Ryan > >> > >> > >> > >> On Mon, Aug 22, 2022 at 10:49 PM Brennan Vincent <[email protected]> > >> wrote: > >>> > >>> On 2022/08/22 20:05:22 Martin Grigorov wrote: > >>>> Hi, > >>>> > >>>> I might be wrong but I think your sample schema should be valid! Does > >> it > >>>> fail with any of the SDKs ? > >>> > >>> Yes. It fails with the Python avro package. > >>> > >>>> > >>>> This part of the spec talks about the namespace, not the type. I.e. > >>>> "namespace": ".ns" would be an error. > >>> > >>> The linked thread ( > >> https://lists.apache.org/thread/q0o58fxgvstvdlgpoyv2pcz53borp587 ) > >>> is a bit vague -- it's not totally clear whether the restriction is > >> meant to apply to > >>> namespaces only, or to fullnames also. > >>> > >>> "The null namespace may not be used in a dot-separated sequence of > >> names." > >>> > >>> certainly makes it sound like it applies to _any_ sequence of names, > >> though, > >>> not just in a namespace field. > >>> > >>>> > >>>> On Mon, Aug 22, 2022 at 10:40 PM Brennan Vincent <[email protected] > >>> > >>>> wrote: > >>>> > >>>>> Hello, > >>>>> > >>>>> https://github.com/apache/avro/pull/917 introduced the following > >> language > >>>>> to the spec: > >>>>> > >>>>>> The null namespace may not be used in a dot-separated sequence of > >> names. > >>>>> > >>>>> Thus ruling out fullnames like ".foo". > >>>>> > >>>>> However, this seems to rule out referring to names in the default > >>>>> namespace from another namespace. > >>>>> > >>>>> For example, this schema was previously allowed by the spec: > >>>>> > >>>>> { > >>>>> "type": "record", > >>>>> "name": "r", > >>>>> "fields": [ > >>>>> { > >>>>> "name": "f", > >>>>> "type": { > >>>>> "type": "record", > >>>>> "name": "r2", > >>>>> "namespace": "ns", > >>>>> "fields": [ > >>>>> { > >>>>> "name": "f2", > >>>>> "type": ["null", ".r"] > >>>>> } > >>>>> ] > >>>>> } > >>>>> } > >>>>> ] > >>>>> } > >>>>> > >>>>> Note ".r" in the type of "f2". This can't be changed to "r", > >>>>> because that would be interpreted as "ns.r" due to "ns" being the > >> nearest > >>>>> enclosing namespace. > >>>>> > >>>>> Thus it seems that the new spec has restricted the set of valid > >> schemas > >>>>> and there is no longer > >>>>> any way to accomplish this. > >>>>> > >>>>> Am I misinterpreting the spec? Does the empty namespace being > >> disallowed > >>>>> in dotted sequences > >>>>> of names only apply to initial name definitions, but not to later > >> name > >>>>> references? Or is there > >>>>> some other way to express this? > >>>>> > >>>>> Here is the initial discussion of this change, where the issue I'm > >> raising > >>>>> here doesn't > >>>>> appear to have come up: > >>>>> https://lists.apache.org/thread/q0o58fxgvstvdlgpoyv2pcz53borp587 > >>>>> > >>>>> Thanks, > >>>>>
