[liblouis-liblouisxml] Re: Metadata in subtables.

  • From: Bert Frees <bertfrees@xxxxxxxxx>
  • To: "liblouis-liblouisxml@xxxxxxxxxxxxx" <liblouis-liblouisxml@xxxxxxxxxxxxx>
  • Date: Thu, 12 Jan 2017 17:49:27 +0100

Having only one way or more than one way to store/look up data is a
different discussion than the one about wanting to hide internal tables and
their metadata I think.

Having two kinds of metadata is just one way to achieve the latter. In
addition, with this solution you can make some metadata fields "passive",
i.e. not taken into account in queries. Whether or not that is useful I
don't want to say, it is just something I have in mind and don't want to
exclude yet.

Another way to distinguishing between top-level and internal tables is
indeed, like you suggested earlier, to have a dedicated metadata field for
it.

I can follow you in most of your arguments, except this sentence:

Table maintainers might want to look up tables for other reasons. Should
they be forced to use more than one tool depending on their reasons?

I still think looking up "translators" (~ top-level tables) and "tables"
(components, files) in general should be kept separated because the two are
different concepts. Maybe all it takes is an argument to the API function
or command line tool to enable search on component level, we don't
necessarily need to have separate tools for that purpose. But I think the
difference is important to be aware of.




2017-01-12 16:38 GMT+01:00 Dave Mielke <dave@xxxxxxxxx>:

[quoted lines by Bert Frees on 2017/01/12 at 13:42 +0100]

But anyway, this doesn't change the fact that tables that are not
top-level
are of no interest to the user (they are only internal artefacts for
organizing the code), so to have metadata in these tables is useless in my
opinion because metadata only makes sense in connection with users (or
programs). Right?

I don't think so. Data is data, and the reason for wanting access to that
data
shouldn't make any difference. What doesn't make sense to me is having more
than one way to sotre/look up data just because its foreseeable uses are
different. To me, that's adding complexity where it isn't requried.

For example, what can a user/program do with the author information of an
internal table?

But why should that matter insofar as how the data is being stored and how
it
can be looked up? While we mightn't think of a reason a user would want to
do
it, does that make it wrong should a user ever think of a reason?

Table maintainers might want to look up tables for other reasons. Should
they
be forced to use more than one tool depending on their reasons?

Of course it is useful to have that information in the file,
but why would you need to be able to programmatically collect that data?

I don't think that the fact that I mightn't want to do it means that it
should
be made impossible.

--
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of
God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: Dave@xxxxxxxxx | Canada  K2A 1H7   | http://FamilyRadio.org/
For a description of the software, to download it and links to
project pages go to http://liblouis.org

Other related posts: