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, >>>>>
