laurelled
commented
4 months ago I've had the time to analyse the complexity of implementing a second round of parsing, based on the current situation. For those who lack the time to read thoroughly, in short my opinion is that its implementation would require a huge effort in terms of refactoring the existing code. We should discuss together on what road to take.
I'll be redundant for the sake of clarity.
Currently, most of the parsing is being done by specific classes that implements the Parser interface, which requires to implement the parse method. I'll paste here one of the classes for reference:
@xmlParser('sic', SicParser)
export class SicParser extends EmptyParser implements Parser<XMLElement> {
attributeParser = createParser(AttributeParser, this.genericParse);
parse(xml: XMLElement): Sic {
const attributes = this.attributeParser.parse(xml);
const { type } = attributes;
return {
type: Sic,
sicType: type || '',
class: getClass(xml),
content: parseChildren(xml, this.genericParse),
attributes,
};
}
}There's also that @xmlParser('sic', SicParser), which comes pretty handy because it maps the tag name to its parser. The combination of both the interface implementation and the mapping is great for a generic double-pass parsing. In fact, we would just need to get the tag name, retrieve the corresponding parser class and call the parse method which any of them has.
However, some parsing is not done following this method. For example:
-
Sometimes the association between the string and the parser is not an actual tag name, for example in the named-entity-parser.ts:
@xmlParser('evt-named-entities-list-parser', NamedEntitiesListParser) export class NamedEntitiesListParser extends EmptyParser implements Parser<XMLElement> { ... }That adds up complexity to take care while scanning through the document. Maybe this could be easily fixed by also adding the tag
-
Some tags are not parsed through a parser class which implements the Parser interface and, thus, the parse method. For example, the witness-parser.service.ts :
export class WitnessesParserService { private witListTagName = 'listWit'; private witTagName = 'witness'; private witNameAttr = 'type="siglum"'; private groupTagName = 'head'; private attributeParser = createParser(AttributeParser, parse); constructor( private genericParserService: GenericParserService, ) { } public parseWitnessesData(document: XMLElement): Witnesses { const lists = Array.from(document.querySelectorAll<XMLElement>(this.witListTagName)); return { witnesses: this.parseWitnessesList(lists), groups: this.parseWitnessesGroups(lists), }; } private parseWitnessesList(lists: XMLElement[]) { const parsedList = lists.filter((list) => !isNestedInElem(list, list.tagName)) .map((list) => this.parseWitnesses(list)) .reduce((x, y) => x.concat(y), []); return parsedList; }It doesn't also include the mapping between
listWitand this class.structure-xml-parser.service.ts, which is much more complicated, works also this way.
Refactoring those problems is not straight-forward and would require thorough discussions with other devs, and from my understanding right now it's not really a good time for that. We should still discuss how to proceed, as it's a pretty important feature for the stand-off apparatus implementation.
RobertoRDT
ajf-ajf
At the time of writing, EVT 3 parsing of TEI elements is sequential, element by element, which makes it problematic to refer to elements that are at a later position than the currently parsed element. For example, to avoid the problem of data redundancy in TEI encoding for authorial philology, a solution based on the
copyofattribute would be very effective:<mod change="layer-0" xml:id="MS_12_23">original text</mod><mod change="layer-1"><mod change="copyof="#MS_12_23"/></mod>This would also be a very useful mechanism in many other situations, e.g. to put together text based on portions of other separate documents and other stand-off use cases. However, since EVT 3 proceeds sequentially, when it encounters
<del copyof="#MS_12_23"/>it would not yet have parsed the contents of<mod change="strato-0" xml:id="MS_12_23">(authorial philology encoding proceeds in reverse chronological order, most recent text first) and thus that node would not yet exist. Another currently impossible use case: retrieving the content of a footnote in the<back>, or of a bibliographic entry also in the<back>.Possible solutions: 1) second round of parsing with only an actual reference to the external element, which, although it would increase the start-up time if the functionality were used intensively, would not have a particular impact on performance; 2) on-demand parsing of the requested node not yet encountered with a copy of the same in its own data structure (and thus duplication + memory costs).