User talk:Dmsmith/KJV 2.6 - Revision history

David Haslam: /* Revision History */ 2.10.2

2023-05-04T10:32:03Z

Revision History: 2.10.2

← Older revision		Revision as of 10:32, 4 May 2023
Line 18:		Line 18:
	! width="10%"\|Date		! width="10%"\|Date
	! width="85%"\|Description		! width="85%"\|Description
			\|-
			\| 2.10.2
			\| 2021-04-04
			\| Emergency update<ref>This was an out of band release by CrossWire's founder. The XML source text wasn't updated.</ref> to fix errant article Strong's markup in Romans 3:26
	\|-		\|-
	\| 2.9		\| 2.9

David Haslam: /* fine grain operators */ reply

2016-01-25T14:14:44Z

fine grain operators: reply

← Older revision		Revision as of 14:14, 25 January 2016
Line 163:		Line 163:
	:The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)		:The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)
	:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)		:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)
			:::That's a good point about substrings. We need to develop a tighter specification for the '''@s[text]''' operator, but one that gives much more flexibility of use, while retaining precision for word locations. [[User:David Haslam\|David Haslam]] 07:14, 25 January 2016 (MST)

David Haslam: /* fine grain operators */ reduced indents

2016-01-25T14:11:34Z

fine grain operators: reduced indents

← Older revision		Revision as of 14:11, 25 January 2016
Line 160:		Line 160:
	=== Related discussion ===		=== Related discussion ===
	==== fine grain operators ====		==== fine grain operators ====
	::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)		The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)
	::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)		:The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)
	:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)		:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)

David Haslam: /* Related discussion */ ==== fine grain operators ====

2016-01-25T14:10:34Z

Related discussion: ==== fine grain operators ====

← Older revision		Revision as of 14:10, 25 January 2016
Line 159:		Line 159:
	[[User:David Haslam\|David Haslam]] 05:16, 25 January 2016 (MST)		[[User:David Haslam\|David Haslam]] 05:16, 25 January 2016 (MST)
	=== Related discussion ===		=== Related discussion ===
			==== fine grain operators ====
	::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)		::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)
	::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)		::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)
	:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)		:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)

David Haslam: /* catchWord osisRef */ === Related discussion ===

2016-01-25T14:09:34Z

catchWord osisRef: === Related discussion ===

← Older revision		Revision as of 14:09, 25 January 2016
Line 158:		Line 158:

	[[User:David Haslam\|David Haslam]] 05:16, 25 January 2016 (MST)		[[User:David Haslam\|David Haslam]] 05:16, 25 January 2016 (MST)
			=== Related discussion ===
	::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)		::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)
	::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)		::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)
	:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)		:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)

Dmsmith: /* Auhoritative reference text for red letter markup */

2016-01-25T13:49:05Z

Auhoritative reference text for red letter markup

← Older revision		Revision as of 13:49, 25 January 2016
Line 12:		Line 12:
	# words tagged as the divine name		# words tagged as the divine name
	# extracts which include the tagged divine name		# extracts which include the tagged divine name

	~~== Auhoritative reference text for red letter markup ==~~

	~~Since when did the Old Scofield become our reference text for this purpose? cf. [https://en.wikipedia.org/wiki/Red_letter_edition]. [[User:David Haslam\|David Haslam]] 05:50, 19 February 2014 (MST)~~
	: During my earlier efforts, I found that there were lots of variations on the texts. I was wanting one that the KJV Only adherents felt was more accurate 1769 text. I found various listings of differences between current and "true" and examined dozens of dead tree texts in several stores. Both combined to come up with the Old Scofield. Also, it was important to avoid copyright claims based upon minor changes in the text. Additionally, I worked with Tim Lanfear who was doing the CCEL KJV to compare various eTexts. Those comparisons yielded differences that needed to be verified in an independent text. Thus the need for a dead tree text. While I was working on this, several websites that were dedicated to producing a "true" text were abandoned with chagrin that it is not a doable task apart from having a facsimile of the 1769, which is not known.
	: Regarding Red Letters, I don't have a better resource. I'd love the "original" by the person who first did it, or a greater authority. What I have is a consistent authority. In doing the verification of the markup, I flipped through every page of the Old Scofield and compared it visually to BibleDesktop's display of the module. I also reviewed lists which various people provided me. Most were regarding words attributed to Jesus.
	~~:--[[User:Dmsmith\|Dmsmith]] 06:29, 19 February 2014 (MST)~~

	== Revision History ==		== Revision History ==

David Haslam: /* catchWord osisRef */ updated stats after further changes

2016-01-25T12:16:42Z

catchWord osisRef: updated stats after further changes

← Older revision		Revision as of 12:16, 25 January 2016
Line 153:		Line 153:
	* 6958 = total, of which		* 6958 = total, of which
	* 5242 = do not contain a space		* 5242 = do not contain a space
	* ~~5866~~ = now have osisRef (1 of which requires reverting)<ref><code><catchWord osisRef="Num.26.39@s[Shupham…Hupham]">Shupham…Hupham</catchWord></code></ref>		* 5958 = now have osisRef (1 of which requires reverting)<ref><code><catchWord osisRef="Num.26.39@s[Shupham…Hupham]">Shupham…Hupham</catchWord></code></ref>
	* ~~1092~~ = are still without osisRef, of which		* 1000 = are still without osisRef, of which
	* ~~0079~~ = are ~~single~~ keywords in verse 1 for Psalms with titles<ref>~~Currently excluded~~ because the XML ~~line does not~~ start with a verse sID milestone.</ref>		* 0000 = are keywords in verse 1 for Psalms with titles<ref>These are now included because I fixed the XML file such that these lines now start with a verse sID milestone.</ref>

	'''Notes:'''		'''Notes:'''
Line 164:		Line 164:
	::<code><catchWord osisRef="Num.26.39@s[Shupham]-Num.26.39@s[Hupham]">Shupham…Hupham</catchWord></code>		::<code><catchWord osisRef="Num.26.39@s[Shupham]-Num.26.39@s[Hupham]">Shupham…Hupham</catchWord></code>

	[[User:David Haslam\|David Haslam]] 03:11, 24 January 2016 (MST)		[[User:David Haslam\|David Haslam]] 05:16, 25 January 2016 (MST)

	::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)		::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)
	::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)		::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)
	:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)		:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)

Dmsmith: /* catchWord osisRef */ time for invention?

2016-01-24T18:58:23Z

catchWord osisRef: time for invention?

← Older revision		Revision as of 18:58, 24 January 2016
Line 166:		Line 166:
	[[User:David Haslam\|David Haslam]] 03:11, 24 January 2016 (MST)		[[User:David Haslam\|David Haslam]] 03:11, 24 January 2016 (MST)

	:::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)		::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)
	::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)		::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)
			:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)

David Haslam: /* catchWord osisRef */ ::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operat

2016-01-24T17:42:25Z

catchWord osisRef: ::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operat

← Older revision		Revision as of 17:42, 24 January 2016
Line 167:		Line 167:

	:::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)		:::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)
			::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)

Dmsmith: /* catchWord osisRef */

2016-01-24T14:48:25Z

catchWord osisRef

← Older revision		Revision as of 14:48, 24 January 2016
Line 165:		Line 165:

	[[User:David Haslam\|David Haslam]] 03:11, 24 January 2016 (MST)		[[User:David Haslam\|David Haslam]] 03:11, 24 January 2016 (MST)

			:::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)

← Older revision		Revision as of 14:14, 25 January 2016
Line 163:		Line 163:
	:The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)		:The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)
	:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)		:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)
			:::That's a good point about substrings. We need to develop a tighter specification for the '''@s[text]''' operator, but one that gives much more flexibility of use, while retaining precision for word locations. [[User:David Haslam\|David Haslam]] 07:14, 25 January 2016 (MST)

← Older revision		Revision as of 14:10, 25 January 2016
Line 159:		Line 159:
	[[User:David Haslam\|David Haslam]] 05:16, 25 January 2016 (MST)		[[User:David Haslam\|David Haslam]] 05:16, 25 January 2016 (MST)
	=== Related discussion ===		=== Related discussion ===
			==== fine grain operators ====
	::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)		::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)
	::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)		::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)
	:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)		:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)

← Older revision		Revision as of 14:09, 25 January 2016
Line 158:		Line 158:

	[[User:David Haslam\|David Haslam]] 05:16, 25 January 2016 (MST)		[[User:David Haslam\|David Haslam]] 05:16, 25 January 2016 (MST)
			=== Related discussion ===
	::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)		::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)
	::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)		::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)
	:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)		:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)

← Older revision		Revision as of 18:58, 24 January 2016
Line 166:		Line 166:
	[[User:David Haslam\|David Haslam]] 03:11, 24 January 2016 (MST)		[[User:David Haslam\|David Haslam]] 03:11, 24 January 2016 (MST)

	:::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)		::The … was probably an artifact of typesetting margin notes. Limited space, resulting in truncation. I like the idea of a range. Regarding Psalm titles, you can double check the reference by dumping with mod2imp. --[[User:Dmsmith\|Dmsmith]] 07:48, 24 January 2016 (MST)
	::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)		::The range concept could work in a lot of places, but what when the range end word is also found earlier in the verse text than the range begin word? The '''@s[word]''' operator finds only the first occurrence of the word in question. I expect there are many such examples. [[User:David Haslam\|David Haslam]] 10:42, 24 January 2016 (MST)
			:: I think it should be easy to understand that a range is anchored at the start and follows to the end. I'd argue that the @s[a]-@s[b] implies that a and b do not reoccur in the range. Maybe it is lacking a secondary subscript as in @s[a] means the first occurrence, also @s[a][1] means the first occurrence, but @s[a][3] means the third occurrence. Since OSIS is targeted to commentaries as well as Bibles, it should be expected that text referenced by an osisID is large. OSIS has another operator that gives the counted position of the match. I think it counts code points though. IIRC: cp(n). It'd be better to have one that counted words, e.g. wc(n). The further complication is that @s[asdf] might be a substring match rather than a whole word match. --[[User:Dmsmith\|Dmsmith]] 11:58, 24 January 2016 (MST)