Support RFC 3066

[adligo]

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]

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]

Cool that sounds good!

…

On Wed, Aug 21, 2019 at 2:15 PM Seva Safris ***@***.***> 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 <#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 [email protected] skype:adligo1?call Send Me Files Securely: *https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI <https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI>*

[adligo]

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 ***@***.***> wrote: Cool that sounds good! On Wed, Aug 21, 2019 at 2:15 PM Seva Safris ***@***.***> 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 > <#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 ***@***.*** 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 [email protected] skype:adligo1?call Send Me Files Securely: *https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI <https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI>*