OASIS Open Mailing List Archives  ·  All Lists  ·  lexidma  ·  2021-02

lexidma — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Relational remodeling: the diagram


Hi John, On Mon, 15 Feb 2021 at 14:19, John McCrae < [email protected] > wrote: Actually, I am not sure which view you are supporting here. The difference is between (in XML notation) reusing 'Translation' e.g., <Definition> foo <Translation>foo in German</Translation> </Definition> <Example> bar <Translation>bar in German</Translation> </Example> versus introducing specific types: <Definition> foo <DefinitionTranslation>foo in German</ Definition Translation> </Definition> <Example> bar < Example Translation>bar in German</ Example Translation> </Example> Both are fine and have different advantages/disadvantages. The former leading to a smaller and hence easier-to-implement model, I think it's vice versa, the former makes it much harder to use the model (or rather, such a serialization). Having a model "smaller" in terms of number of entities is no big gain, and on contrary, if the same entity plays multiple roles in the model, it makes it much harder to understand and use. Translation is an excellent example of that. In theory, you "just" need to say something is translated, but in practice these translations are never the same from the modelling and usage perspective. Sometimes the translation is just one word, sometimes a whole sentence. In case of examples, it might include references to the headword (e.g. in XML as inline element), for definitions not so much. When processing the data and encountering <Translation> you will need to know which it is to do anything with it, so it is much better to have separate names for each. Best Milos

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]