Comments (4)
Dear @RalphTro,
the example you provided represents an edge case.
(b)
{"example:userListElement": [
"1",
"2",
"3"
]
}
would be my preferred JSON representation.
Actually, in my opinion, this is would be the ideal JSON for such a custom extension:
{"example:userList": [
"1",
"2",
"3"
]
}
It's impossible to come up with a generic way of converting custom extension into into nice looking XML and JSON, without providing an SPI (Service Provider Interface) to the converter, that is responsible for taking care of the tiny details when converting user defined extension.
And that's reason why you ended up geting something between a) and b) 😄
from openepcis-document-converter.
Many thanks for your quick feedback, Sven!
Yes, I think the implication/summary of this matter is: whenever an EPCIS implementation requires to support both syntaxes and has user extensions, the respective solution provider should generate the messages in both XML and JSON/JSON-LD and may provide, if applicable, an SPI to ensure a desired conversion behaviour.
Closing this ticket as this cannot be addressed through the tool.
from openepcis-document-converter.
Dear @RalphTro
I had to re-open this issue because I realized, apart from what we may expect or not expect, or whatever personal preference may exist:
The most important requirement would be, that the conversion is working in such a way, that the event hash generator will always create the same hash for JSON and XML, even it has been converted by the document converter tool.
But that also means if users are actually applying some beautification logic, like I mentioned in my previous comment, this may become a huge issue when creating event hashes.
from openepcis-document-converter.
Dear @sboeckelmann ,
Good point. I agree that this subject may be worth discussing further.
Before we continue though, I think it would be helpful for the SMG to understand the use case. In which situations would this be important to have from your POV?
As soon as we identified a compelling Use Case: I am not sure whether all use/edge cases can be tackled technically (see your earlier comment), so how do you like the idea of at least defining a small set of conventions/rules for the most common user extension structures so that independent implementations translate a given JSON-/JSON-LD structure into XML in a consistent manner? Or do you have sth. different in mind?
from openepcis-document-converter.
Related Issues (3)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openepcis-document-converter.