https://wiki.tei-c.org/api.php?action=feedcontributions&feedformat=atom&user=Desmond 2026-04-21T13:41:10Z User contributions MediaWiki 1.32.0 https://wiki.tei-c.org/index.php?title=Talk:GeneticEditionDraf1Comments&diff=6668 2009-05-29T00:17:31Z

<p>Desmond: </p> <hr /> <div>It would be interesting to get some reactions to these comments. Otherwise it would be fair to assume that these points are conceded.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6587 2009-05-24T11:50:56Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. Is it really possible any longer, for texts that will be subject to anything from mild to extreme overlap, to propose a standard for the future that essentially ignores the overlap problem? The past twenty years of research on this topic cannot be so lightly set aside. <br /> <br /> The proposal also does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they can represent the textual phenomena, and how efficiently they will work in software.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6586 2009-05-24T11:48:47Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. Is it really possible any longer, for texts that will be subject to anything from mild to extreme overlap, to propose a standard for the future that essentially ignores the overlap problem? The past twenty years of research on this topic cannot be so lightly set aside.<br /> <br /> The proposal also does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they can represent the textual phenomena, and how efficiently they will work in software.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6585 2009-05-24T11:48:26Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. Is it really possible any longer, for texts that will be subject to anything from mild to extreme overlap, to propose a standard for the future that essentially ignores the overlap problem? The past twenty years of research on this topic cannot so lightly be set aside.<br /> <br /> The proposal also does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they can represent the textual phenomena, and how efficiently they will work in software.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6584 2009-05-24T11:47:47Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. Is it really possible any longer, for texts that will be subject to anything from mild to extreme overlap, to propose a standard for the future that essentially ignores the overlap problem? The past twenty years of research on this topic cannot simply be set aside.<br /> <br /> The proposal also does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they can represent the textual phenomena, and how efficiently they will work in software.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6583 2009-05-24T08:19:13Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. Is it really possible any more, for texts that will be subject to anything from mild to extreme overlap, to propose a standard for the future that essentially ignores the overlap problem? The past twenty years of research cannot simply be ignored.<br /> <br /> The proposal also does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they can represent the textual phenomena, and how efficiently they will work in software.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6582 2009-05-24T08:18:41Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. Is it really possible any more, for texts that will be subject to anything from mild to extreme overlap, to propose a standard for the future that essentially ignores the overlap problem? The past twenty years of research into that cannot simply be ignored.<br /> <br /> The proposal also does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they can represent the textual phenomena, and how efficiently they will work in software.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6581 2009-05-22T22:04:21Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they can represent the textual phenomena, and how efficiently they will work in software.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6563 2009-05-22T07:30:26Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they represent the textual phenomena, and how efficiently they will work in software.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6536 2009-05-21T23:28:05Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they represent the textual phenomena, and how efficiently they work in software.</div>

Desmond https://wiki.tei-c.org/index.php?title=Talk:GeneticEditionDraf1Comments&diff=6535 2009-05-21T22:49:01Z

<p>Desmond: New page: It would be interesting to get some reactions to these comments.</p> <hr /> <div>It would be interesting to get some reactions to these comments.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6534 2009-05-21T22:42:53Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. The excessive use of linking between XML elements to represent complex textual phenomena, as described in the proposal and its supporting documentation, can only result in spaghetti-like markup that will be difficult to edit, excessively complex, incomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they represent the textual phenomena, and how efficiently they work in software.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6533 2009-05-21T22:12:30Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. The excessive use of linking between XML elements to represent complex textual phenomena, as described in the proposal and its supporting documentation, can only result in spaghetti-like markup that will be difficult to edit, excessively complex, incomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they represent the textual phenomena, and how efficiently they work in software.<br /> <br /> The public discussion of this draft is also a little underwhelming. Most of those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6532 2009-05-21T22:12:12Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. The excessive use of linking between XML elements to represent complex textual phenomena, as described in the proposal and its supporting documentation, can only result in spaghetti-like markup that will be difficult to edit, excessively complex, incomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they will represent the textual phenomena, and how efficiently they will work in software.<br /> <br /> The public discussion of this draft is also a little underwhelming. Most of those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6531 2009-05-21T22:11:47Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. The excessive use of linking between XML elements to represent complex textual phenomena, as described in the proposal and its supporting documentation, can only result in spaghetti-like markup that will be difficult to edit, excessively complex, incomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, how accurately they represent the textual phenomena, and how efficiently they will work in software.<br /> <br /> The public discussion of this draft is also a little underwhelming. Most of those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6530 2009-05-21T20:55:39Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. The excessive use of linking between XML elements to represent complex textual phenomena, as described in the proposal and its supporting documentation, can only result in spaghetti-like markup that will be difficult to edit, excessively complex, incomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, what functional advantage they expect to result from the proposed modifications, and how efficiently they will work in software.<br /> <br /> The public discussion of this draft is also a little underwhelming. Most of those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6529 2009-05-21T20:55:15Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. The excessive use of linking between XML elements to represent complex textual phenomena, as described in the proposal and its supporting documentation, can only result in spaghetti-like markup that will be difficult to edit, excessively complex, incomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications, and how efficiently they will work in software.<br /> <br /> The public discussion of this draft is also a little underwhelming. Most of those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6528 2009-05-21T20:54:46Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. The excessive use of linking between XML elements to represent complex textual phenomena, as described in the proposal and its supporting documentation, can only result in spaghetti-like markup that will be difficult to edit, excessively complex, incomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications, and how they will work in software.<br /> <br /> The public discussion of this draft is also a little underwhelming. Most of those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6527 2009-05-21T20:51:03Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical in structure. The excessive use of linking between XML elements to represent complex textual phenomena, as described in the proposal and its supporting documentation, can only result in spaghetti-like markup that will be difficult to edit, excessively complex, incomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.<br /> <br /> The public discussion of this draft is also a little underwhelming. Most of those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6526 2009-05-21T20:50:41Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts, which are primarily non-hierarchical. The excessive use of linking between XML elements to represent complex textual phenomena, as described in the proposal and its supporting documentation, can only result in spaghetti-like markup that will be difficult to edit, excessively complex, incomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.<br /> <br /> The public discussion of this draft is also a little underwhelming. Most of those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6525 2009-05-21T20:43:08Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. The excessive use of linking between XML elements to represent complex textual phenomena, as described in the proposal and its supporting documentation, can only result in spaghetti-like markup that will be difficult to edit, excessively complex, incomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.<br /> <br /> The public discussion of this draft is also a little underwhelming. Most of those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6524 2009-05-21T20:42:18Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. The excessive use of linking between XML elements to represent complex textual phenomena, as described in the proposal and its supporting documentation, can only result in spaghetti-like markup that will be difficult to edit, excessively complex, uncomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.<br /> <br /> The public discussion of this draft is also a little underwhelming. Most of those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6523 2009-05-21T20:39:53Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. The proposal's excessive use of linking between XML elements to represent complex textual phenomena can only result in spaghetti-like markup that will be difficult to edit, excessively complex, uncomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.<br /> <br /> The public discussion of this draft is also a little underwhelming. Most of those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6522 2009-05-21T20:38:59Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. The proposal's excessive use of linking between XML elements to represent complex textual phenomena can only result in spaghetti-like markup that will be difficult to edit, excessively complex, uncomputable, and inadequate in its representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.<br /> <br /> The public discussion of this draft is also a little underwhelming. Those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6521 2009-05-21T20:37:03Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. The proposal's excessive use of linking between XML elements to represent complex textual phenomena can only result in spaghetti-like markup that will be difficult to edit, excessively complex, and provide an inaccurate representation of the data.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.<br /> <br /> The public discussion of this draft is also a little underwhelming. Those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6520 2009-05-21T20:33:30Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.<br /> <br /> The public discussion of this draft is also a little underwhelming. Those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open, online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6519 2009-05-21T20:32:13Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.<br /> <br /> The public discussion of this draft is also a little underwhelming. Those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open and online discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6518 2009-05-21T20:31:15Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.<br /> <br /> The public discussion of this draft is also a little underwhelming. Those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring a result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6517 2009-05-21T20:30:46Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.<br /> <br /> The public discussion of this draft is also a little underwhelming. Those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open discussion forum would be normal. Instead we have a small group of academics who discuss the contents behind closed doors. End users may perhaps be excused for ignoring the result which is not subject to true peer review.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6516 2009-05-21T20:28:23Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.<br /> <br /> The public discussion of this draft is also a little underwhelming. Those who will be expected to use the encoding guidelines for genetic editions will have had no say in its development. In this Web 2.0 age at least an open discussion forum would be normal. Otherwise the end users may perhaps be excused for ignoring it.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6511 2009-05-20T21:25:58Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6510 2009-05-20T21:25:33Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how can such a mechanism work ''between'' documents, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6505 2009-05-19T20:51:54Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6504 2009-05-19T20:49:13Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. It unfortunately is no longer possible, as in this proposal, to ignore the overlap problem.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6503 2009-05-19T20:48:34Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. It is no longer possible, as the authors of this proposal do, to ignore the overlap problem.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6502 2009-05-19T20:48:05Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. It is no longer possible to ignore the overlap problem.<br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6501 2009-05-19T07:20:49Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these complex genetic texts until it is recognised that they are primarily non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6500 2009-05-19T07:19:25Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are primarily non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6499 2009-05-19T07:18:55Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are fundamentally, and primarily, non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6498 2009-05-19T05:53:22Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are fundamentally non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to result from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6497 2009-05-19T05:51:06Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are fundamentally non-hierarchical. <br /> <br /> The proposal does not explain how it is intended to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to derive from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6496 2009-05-19T01:27:40Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are fundamentally non-hierarchical. <br /> <br /> The proposal does not explain how it is possible to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to derive from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6495 2009-05-19T01:18:57Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. The document-centric approach is a simple reproduction of the source documents, which fails to take full advantage of the digital medium. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are fundamentally non-hierarchical. <br /> <br /> The proposal does not explain how it is possible to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to derive from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6494 2009-05-19T00:42:07Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. The document-centric approach is a naive reproduction of the source documents, which fails to take full advantage of the digital medium. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are fundamentally non-hierarchical. <br /> <br /> The proposal does not explain how it is possible to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to derive from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6493 2009-05-19T00:23:26Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. This document-centric approach is a naive reproduction of the source documents, which fails to take full advantage of the digital medium. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are fundamentally non-hierarchical. <br /> <br /> The proposal does not explain how it is possible to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to derive from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6492 2009-05-19T00:22:46Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. This document-centric approach is a naive copying of the source documents, which fails to take full advantage of the digital medium. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are fundamentally non-hierarchical. <br /> <br /> The proposal does not explain how it is possible to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to derive from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6491 2009-05-18T22:13:51Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. The document centric approach is a naive copy of the source documents, which fails to take full advantage of the digital medium. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are fundamentally non-hierarchical. <br /> <br /> The proposal does not explain how it is possible to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to derive from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6490 2009-05-18T22:13:07Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. The document centric approach is thus a naive copy of the source documents, which fails to take full advantage of the digital medium. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are fundamentally non-hierarchical. <br /> <br /> The proposal does not explain how it is possible to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to derive from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6489 2009-05-18T20:39:08Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. The document centric approach is a naive copy of the source documents, which fails to take full advantage of the digital medium. <br /> <br /> The section on 'grouping changes' assumes that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are fundamentally non-hierarchical. <br /> <br /> The proposal does not explain how it is possible to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to derive from the proposed modifications.</div>

Desmond https://wiki.tei-c.org/index.php?title=GeneticEditionDraf1Comments&diff=6488 2009-05-18T20:25:14Z

<p>Desmond: </p> <hr /> <div>Because it is difficult to record many versions in one file using markup, the proposal recommends a document-centric approach. In this method each physical document is encoded separately, even when they are just drafts of the one text. As a result there is a great deal of redundant information in their representation. This only serves to increase the work of editors and software in maintaining copies of text that are supposed to be linked or identical. It would be much more efficient and simpler to represent each instance of a piece of text that occurs exactly once in a work by a unique piece of text. The document centric approach is a naive copy of the source documents, which fails to take full advantage of the digital medium. <br /> <br /> The section on 'grouping changes' implies that manuscript texts have a structure that can be broken down into a hierarchy of changes that can be conveniently grouped and nested arbitrarily. Similarly in section 4.1 a strict hierarchy is imposed consisting of document-&gt;writing surface-&gt;zone-&gt;line. Since Barnard's paper in 1988 where he pointed out the inherent failure of markup to adequately represent a trivial case of nested speeches and lines in Shakespeare, the problem of overlap has become the dominant issue in the digital encoding of historical texts. This representation, which seeks to reassert the OHCO thesis, which has been withdrawn by its own authors, will fail to adequately represent these genetic texts until it is recognised that they are fundamentally non-hierarchical. <br /> <br /> The proposal does not explain how it is possible to 'collate' XML documents arranged in this structure, especially when the variants are distributed via two mechanisms: as markup in individual files and also as links between documentary versions. Collation programs work by comparing basically plain text files, containing only light markup for references in COCOA or empty XML elements (as in the case of Juxta). The virtual absence of collation programs able to process arbitrary XML renders this proposal at least very difficult to achieve. It would be better if a purely digital representation of the text were the objective, since in this case, an apparatus would not be needed.<br /> <br /> The mechanism for transposition as described also sounds infeasible. It is unclear what is meant by the proposed standoff mechanism. However, if this allows chunks of transposed text to be moved around, this will fail if the chunks contain non-well-formed markup or if the destination location does not permit that markup in the schema at that point. Also if transpositions between physical versions are allowed - and this actually comprises the majority of cases - how is such a mechanism to work, especially when transposed chunks may well overlap?<br /> <br /> The main advantage claimed for HNML and LEG/GML (=Genetic Markup Language) is that they are more succinct than a TEI encoding. If the proposed markup encoding standard is incorporated into TEI, however, this advantage will be lost. The proposed codes will just become part of the more generic, and hence more verbose, TEI language. There seems very little in the sketched proposals here that cannot already be encoded in the TEI Guidelines as they currently stand. The authors should spell out clearly which elements and attributes in their view need to be added, and what functional advantage they expect to derive from the proposed modifications.</div>

Desmond