[liblouis-liblouisxml] Re: Liblouis table header
- From: Ken Perry <kperry@xxxxxxx>
- To: "liblouis-liblouisxml@xxxxxxxxxxxxx" <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Wed, 22 Oct 2014 02:38:55 +0000
Best way to figure out what we want is not to just ask what fields we want it
would be better to write a few use cases and then build the data to fit those
cases. Maybe have a time frame that everyone puts in their use case and after
that time build the field data to fit the input you get.
Ken
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Bert Frees
Sent: Tuesday, October 21, 2014 2:09 PM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Liblouis table header
Agreed, but it can be speed up by only allowing metadata on the very first
lines (and not allowing localisation strings), and through caching. You could
even generate your central file and use that whenever it's available.
We don't need to decide yet *where* we put the metadata. First we need to
figure out what that metadata should be and work out an algorithm that will
find the right table based on the metadata.
Ken Perry writes:
> The problem with doing them in the table is it will slow down finding all the
> tables. For instance why look through tables like low digits or lattin 6 dot
> and lattin 8 dot for information when what you are looking for is language
> files and their names. Your making it slower by forcing what ever you want
> to look at these fields to go through every file.
>
> Ken
>
> -----Original Message-----
> From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
> [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of
> Michael Whapples
> Sent: Tuesday, October 21, 2014 1:41 PM
> To: liblouis-liblouisxml@xxxxxxxxxxxxx
> Subject: [liblouis-liblouisxml] Re: Liblouis table header
>
> I agree, I think it is a good idea to have it that the table is self
> contained (IE. it has all these properties defined in itself). This
> simplifies it should a user want to add a table, just put the table in the
> table directory, no editing data files.
>
> Localisation is something else.
>
> Michael Whapples
> On 21/10/2014 17:21, Bert Frees wrote:
>> It's not a bad idea and it's an approach that I and others have been
>> using in our applications.
>>
>> But whether we put this information in the table file itself or in
>> central file is really not that crucial. What matters is that a table
>> can have a lot of properties, and we need a good mechanism to select
>> tables based on a number of parameters. And, most important, that
>> we're all using the same tables across applications.
>>
>> For the selection criteria, I would say put them in the table file
>> itself because then when looking for tables you're not limited to the
>> ones that are included in the main distribution (unless you can have
>> several such "index cards", as you call them, on your table path).
>> Also, I think it's nice to have all the information about a table right at
>> the top.
>>
>> For localization strings, I'm not sure yet if we should put them in
>> the table, because there can be a lot of them so it could bloat the table.
>>
>> By the way, Ken, here are some links to related conversation we've
>> had in the past (can't find them all).
>>
>> //www.freelists.org/post/liblouis-liblouisxml/Translatable-table
>> -
>> names-in-Liblouis-independent-with-screen-readers-now-used-methods-po
>> s
>> sible-doing-this
>> //www.freelists.org/post/liblouis-liblouisxml/Grouping-tables-ac
>> c
>> ording-to-language-and-Braille-code
>> //www.freelists.org/post/liblouis-liblouisxml/List-of-Braille-ta
>> b
>> les-standalone,15
>> //www.freelists.org/post/liblouis-liblouisxml/Table-of-human-rea
>> d
>> able-tables
>>
>>
>> Ken Perry writes:
>>
>>> If not xml it still is not a bad idea to have this in an index card.
>>> I just can't see why you would want this in the top of every table.
>>> So whatever you want to call the file that would be fine with me.
>>>
>>> Ken
>>>
>>> -----Original Message-----
>>> From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
>>> [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of
>>> Keith Creasy
>>> Sent: Tuesday, October 21, 2014 10:16 AM
>>> To: liblouis-liblouisxml@xxxxxxxxxxxxx
>>> Subject: [liblouis-liblouisxml] Re: Liblouis table header
>>>
>>> Ken.
>>>
>>> As an XML fan I like the idea but really since LibLouis doesn't use XML
>>> anywhere else it makes more sense to me to keep it as a simple key/value
>>> table. Why add XML dependencies to something that has no compelling need to
>>> use it?
>>>
>>>
>>> -----Original Message-----
>>> From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
>>> [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Ken
>>> Perry
>>> Sent: Tuesday, October 21, 2014 9:55 AM
>>> To: liblouis-liblouisxml@xxxxxxxxxxxxx
>>> Subject: [liblouis-liblouisxml] Re: Liblouis table header
>>>
>>> I wonder though if this would not be better done as an extra xml
>>> file like an index card sort of like how a daisy book is done. For
>>> example the xml file could have all the info for a certain set of
>>> tables. It could also list all the tables that are included in the
>>> grouping for example for ueb it could have all the latten files and
>>> the braille pattern file listed as files to include if you want
>>> contracted ueb. Thus the xml tool could be used not only as a
>>> pretty way to show the name of the tables but also a way to group sets of
>>> tables together so you know what tables are affected when you make changes.
>>> An index card could also show relationships between different tables.
>>> And you wouldn't have to have info at the top of every table just a
>>> card for each language or braille type.
>>>
>>> Ken
>> For a description of the software, to download it and links to
>> project pages go to http://www.abilitiessoft.com
>
> For a description of the software, to download it and links to project
> pages go to http://www.abilitiessoft.com For a description of the
> software, to download it and links to project pages go to
> http://www.abilitiessoft.com
For a description of the software, to download it and links to project pages go
to http://www.abilitiessoft.com
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
