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