Talk:Whiteboard - Revision history

Gregs650: /* Modules - simplify more for those who are not experts in SWORD */

2024-09-26T23:03:46Z

‎Modules - simplify more for those who are not experts in SWORD

Gregs650: /* Modules - simplify more for those who are not experts in SWORD */

2024-09-26T23:01:05Z

‎Modules - simplify more for those who are not experts in SWORD

Gregs650: /* Divide complexity to smaller parts for non-experts? */ new section

2024-02-08T23:36:36Z

‎Divide complexity to smaller parts for non-experts?: new section

New page

== Divide complexity to smaller parts for non-experts? ==

Obviously, there are very smart people doing the SWORD Project. I've coded a little and even with that a big learning curve is still perceived for SWORD. Is it possible to at least consider how the [https://wiki.crosswire.org/Main_Page developersWiki] or major SWORD code units might divide or simplify more?

Is some of the Open Application Programming Interface (API) Specification (OAS) possible to apply? The simple terms client server were observed in it instead of front/back end currently used. The client server model seems to put Modules in the server category, in contrast to both categories as currently observed in the developers wiki. The OAS had a concept for representational state transfer [https://en.wikipedia.org/wiki/REST#Classification_models REST], which encourages that the server be a layered system. The SWORD Bible Tool (https://www.crosswire.org/study/) is excellent, but the URLs did not demonstrate layering as partly discussed for level 3 of the [https://en.wikipedia.org/wiki/Richardson_Maturity_Model RichardsonMaturityModel]). The term "engine" is understood, but that term by itself does not predict layers. Layering might communicate the reasons for linking in a huge library (C/C++). If a huge library is included, a new non-expert thinking they will just learn SWORD in a given time-frame may find out about another training for the huge library later, and be discouraged.

Would more code divisions by 1) specification and 2) tool help make any parts smaller? For example, naming layers of code by World Wide Web Consortium (W3C) recommendation, European Computer Manufacturers Association (ECMA)/JavaScript, Internet Engineering Task Force (IETF), RFC, etc. If a SWORD program has many standards or commercial products mixed inside, a new person who never heard of these maybe confounded, especially if new terms have been created for the overall system. These divisions might also recognize choices between basic JavaScript or jQuery/AJAX. Maybe they could help figure out if there was any standardization between the C++ and Java engines?

This comment was not from the perspective of creating more work. The purpose was understanding the whole better in order to choose how to drop into one small project somewhere (non random entry). Psalm 19:7 (LSB).

@@ Line 3: / Line 3: @@
 Obviously, there are very smart people doing the SWORD Project. Even with a little coding, a substantial learning curve was still perceived for SWORD. While this maybe because I learn slower, is the following reasonable as a module simplification?
-Supply, double check, or explain module examples to enable those who prepare content to annotate basic SWORD module sections (or TEI tags) without requiring operation of a SWORD utility, or successfully producing a SWORD module. Different XML tags were observed at a site with Hebrew scriptures at <a href="https://tanach.us/">tanach.us</a> and a site with Greek scriptures at <a href="https://github.com/LogosBible/SBLGNT">SBLGNT</a>. The folks at those sites probably have above average software expertise, and even with the expertise, different XML tags were observed that didn't look compatible. If incompatible among themselves, it is assumed they are also not compatible with SWORD module utility, and present inefficiency between projects.
+Supply, double check, or explain module examples to enable those who prepare content to annotate basic SWORD module sections (or TEI tags) without requiring operation of a SWORD utility, or successfully producing a SWORD module. Different XML tags were observed at a site with Hebrew scriptures at [https://tanach.us/ tanach.us] and a site with Greek scriptures at [https://github.com/LogosBible/SBLGNT SBLGNT]. The folks at those sites probably have above average software expertise, and even with the expertise, different XML tags were observed that didn't look compatible. If incompatible among themselves, it is assumed they are also not compatible with SWORD module utility, and present inefficiency between projects.
 If the SWORD tags are not simple enough, this might increase the temptation for future programmers making new software to make it incompatible with existing SWORD code, in like manner as the data. Expecting the proposer of an issue to contribute is OK, but it might not help SWORD if they do a contribution, but the contribution is incompatible with SWORD.

@@ Line 1: / Line 1: @@
-== Divide complexity to smaller parts for non-experts? ==
+== Modules - simplify more for those who are not experts in SWORD ==
-Obviously, there are very smart people doing the SWORD Project. I've coded a little and even with that a big learning curve is still perceived for SWORD. Is it possible to at least consider how the [https://wiki.crosswire.org/Main_Page developersWiki] or major SWORD code units might divide or simplify more?
+Obviously, there are very smart people doing the SWORD Project. Even with a little coding, a substantial learning curve was still perceived for SWORD. While this maybe because I learn slower, is the following reasonable as a module simplification?
-Is some of the Open Application Programming Interface (API) Specification (OAS) possible to apply? The simple terms client server were observed in it instead of front/back end currently used. The client server model seems to put Modules in the server category, in contrast to both categories as currently observed in the developers wiki. The OAS had a concept for representational state transfer [https://en.wikipedia.org/wiki/REST#Classification_models REST], which encourages that the server be a layered system. The SWORD Bible Tool (https://www.crosswire.org/study/) is excellent, but the URLs did not demonstrate layering as partly discussed for level 3 of the [https://en.wikipedia.org/wiki/Richardson_Maturity_Model RichardsonMaturityModel]). The term "engine" is understood, but that term by itself does not predict layers. Layering might communicate the reasons for linking in a huge library (C/C++). If a huge library is included, a new non-expert thinking they will just learn SWORD in a given time-frame may find out about another training for the huge library later, and be discouraged.
+If the SWORD tags are not simple enough, this might increase the temptation for future programmers making new software to make it incompatible with existing SWORD code, in like manner as the data. Expecting the proposer of an issue to contribute is OK, but it might not help SWORD if they do a contribution, but the contribution is incompatible with SWORD.