Test viability of abstract even further mappings from XML-like formats vs HXL tabular format using as base XML nested tags (vs HXL attributes) using as baseline concept/language/term.

[fititnt]

Test what the title says.

I'm not very sure if this is possible without making it more complicated to the end user, but I think it may be viable to go a bit less repetitive.

The general idea of how to organize rows in a table in concepts on XML (which could go several rows, with relationships) needs a lot of creativity. The second (but already likely to be solved) is how to generalize language code parsing. Then, there are the terms.

But, after these three big groups, I'm starting to think that additional data attached to these groups (if done with the same logic, requiring adding more lines on python) may actually be worth abstract.

One way to generalize such an idea

Note: is obviously possible to add more semantics by adding more lines to python. The point here is make the ontologia even more powerful

In the current state, the way things are on HXLTM on tabular format (aka HXL, with some extra attributes) it could be ported to a direct mapping. For example, when reading from XML (it could be JSON or YAML, but we would need to make sure to avoid adding powerful features of XML not portable) we already know when we are at concept, language or term level. So In theory the generalization here would be some XML tag (that could appear at 3 levels) with an attribute that tells what inner XML tags (or HXL in tabular format, additional attributes) how to change the strategy.

Some disadvantages

• This implementation would enforce HXLTM be more strict on order of tags than HXL allow.     - This may not be an issue if new attributes are only one level deep than each baseline; but cannot be generalized without invert orders of tags on XML; it coild convert from tabular HXL and XML, but would not make much sense to other tools trying to parse the XML.
• Well, this is not implemented. It may not be as simple to generalize.

Some advantages:

• This obviously makes it much more generalized to convert HXLTM tabular format to XML (and go back) while still somewhat aware what the user is doing. The potential caotic part is reduced.     - And, if XML forma be intentionally not as complex, also viable to reuse the logic to use JSON or YAML as storage.         - Note that allowing somewhat intuitive editing by hand is interesting. But either tabular data, or XML/JSON/YAML at some point would be complex, because the subject is complex.
• This makes it easy to add new complex data structures without previous planning.
  • On downside is, despite being editing XML (which have higher user expectation of have some way to validate, people who uses JSON may not care as much to have JSON Schemas) the nature of allow this flexibility means never be able to create a schema to validate what is intentionally open to be flexible. This means more human error.
    • Part of these errors may be easier to catch if validating exported formats to TBX/TMX/XLIFF, but, again, create custom formats means that some information may not map to other specifications.