Classes were developed from the most basic (selection and transformation steps) to the more complex (domain). It would now make sense to rethink the output interfaces so they are more easily handled by the consumer classes (above in the hierarchy). Ideally, they should more or less resemble what the top (domain) class returns.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T302431 Normalize output interfaces | |||
| Open | None | T305273 The TranslationOutput returned by a Domain object's translate method may include an array of citations |
Event Timeline
Comment Actions
It may have happened that, in an effort to simplify the outputs from each object class, we may have ended with oversimplified outputs, leaving little room for changes in consumer classes up in the hierarchy.
For example, it has just happened to me that I wanted to add the label of the template used for a translation in the Web2Cit-Server output, to realize that template labels had not been included in the Web2Cit-Core output.
Comment Actions
Domain's translate method output:
- May include all translation templates in the same URL path pattern group as the target, regardless of whether they are applicable or not, and even regardless of whether they were tried or not. Not applicable translation templates may simply include the applicable=false property, and templates not tried may simply include an applicable=undefined property.
- May be organized in targets. This way, we could have a targets property, including one or more translation targets, and each of them including one or more translation results, one per template (see previous point). The test method of the Domain object class may then simply add a test object to each target, and a score object to each result.