Namespacing of non-standard attributes uses "./" which does not work with standard json parser libraries
BLR-0118 opened this issue · comments
Name: Protocol Specifications
Title: "Namespacing of non-standard attributes uses "./" which does not work with standard json parser libraries"
Labels: C4GT Community, Protocol Draft
Description
As per the Beckn governance model for contribution, non-standard attributes need to be prefixed by "./". This breaks standard JSON parser libraries. Can this be changed to a different prefix, such as "ns-"?
Goals
- Update governance model
Expected Outcome
- All non-standard attributes transmitted in beckn API calls to be json parser friendly
Project
Beckn
Organization Name:
Beckn Open Collective
Domain
Others
Tech Skills Needed:
Open API 3.0
Beckn protocol
Mentor(s)
Ravi Prakash
Complexity
Medium
Category
Bug
Sub Category
Reproducible
Given early adoption of the protocol, we should surely see if many of the extensions can actually be brought in aa standard attributes. Allows a larger global interoperability play.
Second, if there are two networks and both have a few ns attributes (is ns followed by network namespace or just ns?) that are conflicting, inter-network (commerce to mobility or logistics for example) calls will immediately break.
So, I suggest we do the following:
- Immediate analysis of extended attributes and see how much of those can be standardized (given much are optional attachments) @BLR-0118 @core-wg-admin
- Use
nsalong with network specific name space as prefix rather than justns(I don't remember if it was just that,. sorry if full name space is already there) allowing different networks not to create conflicts. @BLR-0118 @core-wg-admin
ONDC extended attributes are here
Thanks @BLR-0118. Much of these are so common attributes in any retail transaction and I don't see a reason why they can't be part of core. @core-wg-admin @sjthnrk
From naming standpoint I prefer the network domain namespace (org.ondc in this case) prefix to ensure various networks are not conflicting. @core-wg-admin we should be able to define namespace once and use a smaller local variable across the json instead of always using the full namespace (which can make json bigger). Possible?
"." will create a problem as JSON parsers use it to identify nested objects. Can we instead use "/"?
e.g. "@org/ondc/cod_available" instead of "@org.ondc.cod_available"
@pramodkvarma @core-wg-admin
@core-wg-admin what so you think? Any json parser friendly notation should be fine, right?
Yes @pramodkvarma. I agree that we should be using JSON parser-friendly characters.
But firstly, I'd like to move the attribute-specific discussions off this thread. @BLR-0118 if you can start a new thread on these attributes, clearly specifying the definition of these terms and why you want to add them to the core spec, we can get it reviewed by the @beckn/core-working-group
Secondly, I propose the following
We can use '@(namespace-type)/(namespace-identifier)/(property-name)' format to specify non-standard attributes. But that poses a new question - what are the ways to ensure uniqueness of namespaces? A country-level registry perhaps?
No need for registries, let us use standard web domain of the network facilitator organization. In the case of ondc, it will be ondc.org. Since website domains are owned and are unique globally, it is fine. While Java etc suggests domain names in reverse, I think we should prefix it with actual network web domain as is (ondc.org instead of org.ondc). E.g., @ondc/org/GSTN_ID
Btw, what goes in namespace-type field?
In @org/ondc/cod_available the "org" was the namespace-type. I didn't realize it could be the website domain extension. So please ignore it.
So basically your're saying that any namespaced attribute will have three parts
- Domain extension,
- Domain name, and
- Attribute name
So if the NFO has an FQDN called mynfo.org and it wants to add an attribute named foo, then the namespaced attribute will be @org/mynfo/foo. Right?
So NFO's must necessarily have a FQDN in order to add non-standard attributes to the specification.
What if there is a domain-specific working group like say DHP that doesn't have a FQDN and wants to add non-standard attributes as it is currently not supported by the core specification. How would that work?
Yes. But I am wondering if we should simply use @domain-name/domain-extention in the same order as we type (in your above example, @mynfo/org rather than reverse @org/mynfo). Will it matter when it comes to uniqueness?
I'm perfectly fine with the suggested format @pramodkvarma i.e @domain-name/domain-extension/attribute.
Therefore an example property like say symptom added by an org say, mynfo.org will be
@mynfo/org/symptom
Can we all agree on this?
Yes, I am OK.
Requesting @beckn/core-working-group to sign-off on this resolution?
Ok from my side in case you are asking me!
Ok from my side too 👍
I am also ok
Ok from my end as well.
Raising a PR to draft
Hi!
Mandatory Details - The following details essential to submit tickets to C4GT Community Program are missing. Please add them!
- Product Name - Please add a heading called Product Name and mention the name of the product below it.
Without these details, the ticket cannot be listed on the C4GT Community Listing.
Please update the ticket