search

jsonx-org / schema

"JSON Schema Definition" (JSD) language that offers a vocabulary to describe the structure and constraining the contents of JSON documents.
https://jsonx.org/schema/
MIT License
4 stars 1 forks source link

Support RFC 3066 #1

Open adligo opened 5 years ago

adligo commented 5 years ago

Hi Seva, Thanks for the link!

After a quick read it looks like this document is one part of what I was suggesting. As far as I can tell rfc3066 covers what language is this schema in. So I suggest sticking with that for;

'what language is this schema in?'

The second part of my suggestion is;

'what was the original language of this schema?'

Assuming the schema was originally constructed in one language 'i.e. English', and then a second schema was added to support another language 'i.e. German'.
To bring things together in an example, perhaps the original English Invoice (XML) schema would have; xml:lang="en" xml:p-lang="en"

And then if it got translated to German the German Invoice (XML) schema would have; xml:lang="de" xml:p-lang="en" p-lang stands for primary language

safris commented 5 years ago

Hi Scott, I will look into the best way to support RFC 3066 in the JSONx Schema. Regarding your request for "primary language":... The logic to "link" schemas together, be it by language or primary language, is an application-specific requirement that is "closed" to a single use-case. The XML Schema specification has a generalized pattern for linking XML documents, called XLink. I would consider implementing an analogous pattern for JSONx. This pattern can thereafter be used to "link" schemas together for any reason, be it primary language, or anything you can imagine, making this kind of pattern "open".

adligo commented 5 years ago

Cool that sounds good!

On Wed, Aug 21, 2019 at 2:15 PM Seva Safris notifications@github.com wrote:

Hi Scott, I will look into the best way to support RFC 3066 in the JSONx Schema. Regarding your request for "primary language":... The logic to "link" schemas together, be it by language or primary language, is an application-specific requirement that is "closed" to a single use-case. The XML Schema specification has a generalized pattern for linking XML documents, called XLink https://en.wikipedia.org/wiki/XLink. I would consider implementing an analogous pattern for JSONx. This pattern can thereafter be used to "link" schemas together for any reason, be it primary language, or anything you can imagine, making this kind of pattern "open".

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jsonx-org/schema/issues/1?email_source=notifications&email_token=ABSJQCO7OYXETPE6P2AAI5TQFWH4HA5CNFSM4IOMSZ62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD422NJI#issuecomment-523609765, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSJQCLYEI6TYC4PPAGHRODQFWH4HANCNFSM4IOMSZ6Q .

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI

adligo commented 5 years ago

Hi Seva,

Today I was thinking about this and I thought it might be useful to mention why I was thinking about it;

Standardized Global Accounting!

Since automated Accounting was one of Alan Turing's original goals, I find it kind of messed up that we still don't have it even close in 2019.

Most accounting systems track expenses through receipts usually tracked as image files with fields typed into databases. This has always annoyed me, and the quick fix is to use a OCR (Optical Character Recognition) scan to convert the receipt to data (DB, JSON, XML, CSV, etc). Which works sometimes but involves the annoying step of scanning the file and verifying the scan.

XML, JSON and CSV are all Human Readable and Machine Readable, but are not End User Readable Friendly. PDFs and EMail receipts are Human Readable, Machine Readable, and End User Readable Friendly, but not a public standard. I would like standardize receipts, and invoices (etc.) so that they can be sent over the socket or through paper in a way that fixes all the issues and most importantly are able to import directly into a software accounting system.

This initially leads me to JSON or XML. The JSON or XML could include Base64 encoded images for the End User Readable Friendly version, or viewers (i.e. a standard that applications like Acrobat Reader) could render the receipt image, that would include a QR code or set of QR codes for scanners to always get it right when the receipt is printed. Also I would greatly prefer field names like 'total_tax' to field names like 'x110399' (I have seen fields like x110399 in some i18n systems).

My guess is that it would take some sort of joint effort between the IFRS https://www.ifrs.org/ and IETF https://www.ietf.org/ to build such a standard. Let me know if you have any thoughts on this topic, I am interested in hearing them. On Wed, Aug 21, 2019 at 3:04 PM Scott Morgan scott@adligo.com wrote:

Cool that sounds good!

On Wed, Aug 21, 2019 at 2:15 PM Seva Safris notifications@github.com wrote:

Hi Scott, I will look into the best way to support RFC 3066 in the JSONx Schema. Regarding your request for "primary language":... The logic to "link" schemas together, be it by language or primary language, is an application-specific requirement that is "closed" to a single use-case. The XML Schema specification has a generalized pattern for linking XML documents, called XLink https://en.wikipedia.org/wiki/XLink. I would consider implementing an analogous pattern for JSONx. This pattern can thereafter be used to "link" schemas together for any reason, be it primary language, or anything you can imagine, making this kind of pattern "open".

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jsonx-org/schema/issues/1?email_source=notifications&email_token=ABSJQCO7OYXETPE6P2AAI5TQFWH4HA5CNFSM4IOMSZ62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD422NJI#issuecomment-523609765, or mute the thread https://github.com/notifications/unsubscribe-auth/ABSJQCLYEI6TYC4PPAGHRODQFWH4HANCNFSM4IOMSZ6Q .

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI

-- Regards, Scott Morgan President & CEO Adligo Inc http://www.adligo.com https://www.linkedin.com/in/scott-morgan-21739415 A+ Better Business Bureau Rating https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256 https://github.com/adligo

By Appointment Only: 1-866-968-1893 Ex 101 scott@adligo.com skype:adligo1?call Send Me Files Securely: https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI