BPG Revision 3 Public Comment Feedback - Revision history

Kshawkin: /* Level 4, Basic Content Analysis */ fixed wiki markup

2009-05-10T19:46:02Z

Level 4, Basic Content Analysis: fixed wiki markup

← Older revision		Revision as of 19:46, 10 May 2009
Line 32:		Line 32:

	* Perhaps add a column indicating the TEI Tite equivalents?		* Perhaps add a column indicating the TEI Tite equivalents?
	* in General Level 4 Recommendations and Examples the examples have (eg) <del rend="overstrike" hand="JHL">their manner</~~del~~> which I suspect should be <del rend="overstrike" hand="#JHL">their manner</~~del~~> since the datatype of @hand is data.pointer.		* in General Level 4 Recommendations and Examples the examples have (eg) <tt><del rend="overstrike" hand="JHL">their manner</del></tt> which I suspect should be <tt><del rend="overstrike" hand="#JHL">their manner</del></tt> since the datatype of @hand is data.pointer.
	** Eek! Of course, you are correct. But it's worse than that, because apparently no one has edited this example yet at all. The values of rend= don't match the recommendations made later in the same document (not a real problem, in my book, as rend= is such a variable), but worst of all, by far, the example is not well-formed (there is an "&" on the last line)!		** Eek! Of course, you are correct. But it's worse than that, because apparently no one has edited this example yet at all. The values of rend= don't match the recommendations made later in the same document (not a real problem, in my book, as rend= is such a variable), but worst of all, by far, the example is not well-formed (there is an "&" on the last line)!

Kshawkin: Reverted edits by Kshawkin (Talk); changed back to last version by Mdalmau

2009-05-06T18:41:19Z

Reverted edits by Kshawkin (Talk); changed back to last version by Mdalmau

← Older revision		Revision as of 18:41, 6 May 2009
Line 32:		Line 32:

	* Perhaps add a column indicating the TEI Tite equivalents?		* Perhaps add a column indicating the TEI Tite equivalents?
	* in General Level 4 Recommendations and Examples the examples have (eg) <~~code><~~del rend="overstrike" hand="JHL">their manner</del~~></code~~> which I suspect should be <~~code><~~del rend="overstrike" hand="#JHL">their manner</del~~></code~~> since the datatype of @hand is data.pointer.		* in General Level 4 Recommendations and Examples the examples have (eg) <del rend="overstrike" hand="JHL">their manner</del> which I suspect should be <del rend="overstrike" hand="#JHL">their manner</del> since the datatype of @hand is data.pointer.
	** Eek! Of course, you are correct. But it's worse than that, because apparently no one has edited this example yet at all. The values of rend= don't match the recommendations made later in the same document (not a real problem, in my book, as rend= is such a variable), but worst of all, by far, the example is not well-formed (there is an "&" on the last line)!		** Eek! Of course, you are correct. But it's worse than that, because apparently no one has edited this example yet at all. The values of rend= don't match the recommendations made later in the same document (not a real problem, in my book, as rend= is such a variable), but worst of all, by far, the example is not well-formed (there is an "&" on the last line)!

Line 56:		Line 56:

	=== On Page Breaks ===		=== On Page Breaks ===
	* "Page breaks should be encoded using the pb element," maybe better: "using <~~code><~~pb/~~></code~~>."		* "Page breaks should be encoded using the pb element," maybe better: "using <pb/>."
	* I find the text a bit confusing, as "should always be contained within a text division" ok, so no ..<~~code><~~/div><pb/><div~~></code~~>... but I don't see that "contained within a text division" implies: "(rather than before the <~~code><~~/div~~></code~~> that ends chapter 2)" (although I do agree that <~~code><~~/div><div><pb/~~></code~~> is better)		* I find the text a bit confusing, as "should always be contained within a text division" ok, so no ..</div><pb/><div>... but I don't see that "contained within a text division" implies: "(rather than before the </div> that ends chapter 2)" (although I do agree that </div><div><pb/> is better)

	=== On Levels ===		=== On Levels ===

Kshawkin: /* On Page Breaks */ wiki markup

2009-05-06T18:39:14Z

On Page Breaks: wiki markup

← Older revision		Revision as of 18:39, 6 May 2009
Line 56:		Line 56:

	=== On Page Breaks ===		=== On Page Breaks ===
	* "Page breaks should be encoded using the pb element," maybe better: "using <pb/>."		* "Page breaks should be encoded using the pb element," maybe better: "using <code><pb/></code>."
	* I find the text a bit confusing, as "should always be contained within a text division" ok, so no ..</div><pb/><div>... but I don't see that "contained within a text division" implies: "(rather than before the </div> that ends chapter 2)" (although I do agree that </div><div><pb/> is better)		* I find the text a bit confusing, as "should always be contained within a text division" ok, so no ..<code></div><pb/><div></code>... but I don't see that "contained within a text division" implies: "(rather than before the <code></div></code> that ends chapter 2)" (although I do agree that <code></div><div><pb/></code> is better)

	=== On Levels ===		=== On Levels ===

Kshawkin: /* Level 4, Basic Content Analysis */ TEI markup now shows

2009-05-06T16:42:35Z

Level 4, Basic Content Analysis: TEI markup now shows

← Older revision		Revision as of 16:42, 6 May 2009
Line 32:		Line 32:

	* Perhaps add a column indicating the TEI Tite equivalents?		* Perhaps add a column indicating the TEI Tite equivalents?
	* in General Level 4 Recommendations and Examples the examples have (eg) <del rend="overstrike" hand="JHL">their manner</del> which I suspect should be <del rend="overstrike" hand="#JHL">their manner</del> since the datatype of @hand is data.pointer.		* in General Level 4 Recommendations and Examples the examples have (eg) <code><del rend="overstrike" hand="JHL">their manner</del></code> which I suspect should be <code><del rend="overstrike" hand="#JHL">their manner</del></code> since the datatype of @hand is data.pointer.
	** Eek! Of course, you are correct. But it's worse than that, because apparently no one has edited this example yet at all. The values of rend= don't match the recommendations made later in the same document (not a real problem, in my book, as rend= is such a variable), but worst of all, by far, the example is not well-formed (there is an "&" on the last line)!		** Eek! Of course, you are correct. But it's worse than that, because apparently no one has edited this example yet at all. The values of rend= don't match the recommendations made later in the same document (not a real problem, in my book, as rend= is such a variable), but worst of all, by far, the example is not well-formed (there is an "&" on the last line)!

Mdalmau: /* Public Comment Feedback */

2009-05-06T15:40:08Z

Public Comment Feedback

← Older revision		Revision as of 15:40, 6 May 2009
Line 4:		Line 4:

	= Public Comment Feedback =		= Public Comment Feedback =
	Posted below are public comments we have received as of May 6, 2009, 9:12 EST for review during our DLF-sponsored meeting on May 6th. Most comments, except for two, posted thus far have been on the TEILIB-L list. The non-list feedback was sent directly to Kevin and Michelle or were part of the BOF discussion and were anonymized.		Posted below are public comments we have received as of May 6, 2009, 11:39 EST for review during our DLF-sponsored meeting on May 6th. Most comments, except for two, posted thus far have been on the TEILIB-L list. The non-list feedback was sent directly to Kevin and Michelle or were part of the BOF discussion and were anonymized.

	Comments can also be followed by searching the TEILIB-L Archive, April 2009, Week 4 threads:		Comments can also be followed by searching the TEILIB-L Archive, April 2009, Week 4 threads:

Mdalmau at 15:39, 6 May 2009

2009-05-06T15:39:12Z

← Older revision		Revision as of 15:39, 6 May 2009
Line 50:		Line 50:
	* Soft hyphens at the end of a line or page were the greatest sinners in terms of unnecessary variance across projects [harvesting texts]. The new guidelines say nothing about EOL phenomena, but this seems to me an area where you can make things simpler for diverse users by nailing down a single practice as a firm standard. Using \u2011 consistently would help.		* Soft hyphens at the end of a line or page were the greatest sinners in terms of unnecessary variance across projects [harvesting texts]. The new guidelines say nothing about EOL phenomena, but this seems to me an area where you can make things simpler for diverse users by nailing down a single practice as a firm standard. Using \u2011 consistently would help.
	* Outsource workflow scenario (needs to be developed, but Tite is a related workflow); Develop and integrate workflows		* Outsource workflow scenario (needs to be developed, but Tite is a related workflow); Develop and integrate workflows
			* that the Guidelines encourage the use of unicode rather than named character entities

	=== On Filenames ===		=== On Filenames ===

Mdalmau: /* TEI Header */

2009-05-06T13:39:45Z

TEI Header

← Older revision		Revision as of 13:39, 6 May 2009
Line 19:		Line 19:
	* The recommendations for imprint/pubPlace and imprint/publisher (within sourceDesc) reference "ISBN" punctuation, but this should be "ISBD" punctuation.		* The recommendations for imprint/pubPlace and imprint/publisher (within sourceDesc) reference "ISBN" punctuation, but this should be "ISBD" punctuation.
	* Provide guidance for how deep to go into the header structure (whether MARC-based or not) and provide rationale for why certain tags (i.e., biblStruct) are recommended		* Provide guidance for how deep to go into the header structure (whether MARC-based or not) and provide rationale for why certain tags (i.e., biblStruct) are recommended
			* Recommendation for if you are using another metadata standard to capture canonical metadata how to recommend how much of that source metadata record to include in the TEI Header.

	== Level 1, Fully Automated Conversion and Encoding ==		== Level 1, Fully Automated Conversion and Encoding ==

Mdalmau: /* Public Comment Feedback */

2009-05-06T13:13:15Z

Public Comment Feedback

← Older revision		Revision as of 13:13, 6 May 2009
Line 4:		Line 4:

	= Public Comment Feedback =		= Public Comment Feedback =
	Posted below are public comments we have received as of May 4, 2009, ~~morning~~ EST for review during our DLF-sponsored meeting on May 6th.		Posted below are public comments we have received as of May 6, 2009, 9:12 EST for review during our DLF-sponsored meeting on May 6th. Most comments, except for two, posted thus far have been on the TEILIB-L list. The non-list feedback was sent directly to Kevin and Michelle or were part of the BOF discussion and were anonymized.
	~~All~~ comments, except for two, posted thus far have been on the TEILIB-L list. The non-list feedback was sent directly to Kevin and Michelle and were anonymized.

	Comments can also be followed by searching the TEILIB-L Archive, April 2009, Week 4 threads:		Comments can also be followed by searching the TEILIB-L Archive, April 2009, Week 4 threads:

Mdalmau: /* TEI Header */

2009-05-06T13:04:53Z

TEI Header

← Older revision		Revision as of 13:04, 6 May 2009
Line 17:		Line 17:
	* "Each <respStmt> must have only one resp child element and one name element, though they may occur in either order." This is rather harsh. TEI doesn't enforce this, and it can lead to massive redundancy, if one <resp> is shared by lots of people. Is there good reasons to limit it this way? I don't see programs having a problem with resp+,name+		* "Each <respStmt> must have only one resp child element and one name element, though they may occur in either order." This is rather harsh. TEI doesn't enforce this, and it can lead to massive redundancy, if one <resp> is shared by lots of people. Is there good reasons to limit it this way? I don't see programs having a problem with resp+,name+
	* I am missing profileDesc/langUsage - I guess that if everything is en(g) then why bother, but if your scope is any language?		* I am missing profileDesc/langUsage - I guess that if everything is en(g) then why bother, but if your scope is any language?
			** In profileDesc, langUsage that element is missing. Needs to be added.
	* The recommendations for imprint/pubPlace and imprint/publisher (within sourceDesc) reference "ISBN" punctuation, but this should be "ISBD" punctuation.		* The recommendations for imprint/pubPlace and imprint/publisher (within sourceDesc) reference "ISBN" punctuation, but this should be "ISBD" punctuation.
			* Provide guidance for how deep to go into the header structure (whether MARC-based or not) and provide rationale for why certain tags (i.e., biblStruct) are recommended

	== Level 1, Fully Automated Conversion and Encoding ==		== Level 1, Fully Automated Conversion and Encoding ==

Mdalmau: /* General recommendations/comments */

2009-05-06T13:02:08Z

General recommendations/comments

← Older revision		Revision as of 13:02, 6 May 2009
Line 47:		Line 47:
	*** Definitely, yes. I mean, I have not thought the details through, but every component of the Guidelines must be validated as far as we possibly can. You'd be amazed (or probably not!) at how many simple errors get caught by the validation of examples and the other parts of the test process.		*** Definitely, yes. I mean, I have not thought the details through, but every component of the Guidelines must be validated as far as we possibly can. You'd be amazed (or probably not!) at how many simple errors get caught by the validation of examples and the other parts of the test process.
	* Soft hyphens at the end of a line or page were the greatest sinners in terms of unnecessary variance across projects [harvesting texts]. The new guidelines say nothing about EOL phenomena, but this seems to me an area where you can make things simpler for diverse users by nailing down a single practice as a firm standard. Using \u2011 consistently would help.		* Soft hyphens at the end of a line or page were the greatest sinners in terms of unnecessary variance across projects [harvesting texts]. The new guidelines say nothing about EOL phenomena, but this seems to me an area where you can make things simpler for diverse users by nailing down a single practice as a firm standard. Using \u2011 consistently would help.
			* Outsource workflow scenario (needs to be developed, but Tite is a related workflow); Develop and integrate workflows


	=== On Filenames ===		=== On Filenames ===