<xdxf> should have 'version' attribute to be true extensible and more

[Alex Enz]

Here I suggest to discuss new features that are dictionary (article)
related and can be put into spec.
Short list of proposed are:
- dictionary index
- embedded XPM

[Sergey]

Good idea.

[Leonīds Sošinskis]

I think that, that dictionary index should be made by the dictionary software developers.
Becase in different cases they might need different structure/format of the index.

What is so magical about XPM format? I'm thinking about base64 though.

[Alex Enz]

I don't see any restrictions against having standardized index file
format for xdxf format. Client software may use it with no need to
index dictionary itself. Yet it must be noted that modifying
dictionary makes related index file invalid. Though single dictionary
without index file is just a raw data that must be parsed and indexed
in some way. Additionally I expect that standardized index can be more
advanced over indexes produced by existing clients. For example, let
we have the following English-Russian article:

<ar><k>cast</k>
<b>I</b>
<dtrn>приведение <co>(<i>к какой-л. форме</i>)</co> || приводить
<co>(<i>к какой-л. форме</i>)</co></dtrn>
<ex>to cast out — отбрасывать <co>(<i>напр., члены ряда</i>)</co></
ex>
- <kref>type cast</kref>
<b>II</b>
<dtrn>изобразительный ряд <co>(<i>создаваемого компьютерного фильма</
i>)</co></dtrn></ar>


This article have one example 'to cast out'. Generic client would
index 'cast' keyword only, but not examples. I consider it as a
serious shortcoming. We may want to find exactly 'cast out' article or
article having such example.
This means that we can't apply on client software to index dictionary
correctly.
Standard index can be produced by some standard xdxf index generator.
That's it. It's up to client software whether to use such index or
not.

[Leonīds Sošinskis]

I'm seriously sure, that creating index should be on the part of the software.
And in all feature lists there is note whether fulltext indexing is performed.
You should just choose the dictionary that supports it :)
By the way, you might want to look at the new XDXF standard - https://github.com/soshial/xdxf_makedict/tree/master/format_standard
Any criticisms are welcome! :)

[Alex Enz]

As far as I understand there are new tags such as <abbreviations>. It looks remarkable. It will make abbreviations and dictionary itself in one file. It's good. I don't see any reason to have them split.

<syn>, <ant>, <hpr> ... these all is good, good, good :).

[Lenny Soshinskiy]

Glad you liked it :) Unfortunately, ther is still lack of support of the functions, if you have any time and skill to help with it, you may join xdxf converter or goldendict xdxf support.

[Alex Enz]

Goldendict is hard to build. It has many deps that should be set optional. For example if I don't need any audio or spelling support I really don't want it. I couldn't test it on my slackware machine. But anyway I work on parallel concurrent project XDClient which is more Unix-oriented.

[Alex Enz]

Did somebody think about creating more general format, not dictionary related? Dictionary is a subclass of reference which is more general. It could be called XRXF - XML Reference eXtensible Format or so. It could be used for storing technical docs, like mans, with very good formatting extended with new tags. Why should we tie to dictionaries?! I investigated web and didn't find any standard format for doc. references. All refs are shipped either as mans or visually formatted HTML. What do you think?

On Monday, June 18, 2012 2:22:32 PM UTC+3, Lenny Soshinskiy wrote:

On Monday, June 18, 2012 2:22:32 PM UTC+3, Lenny Soshinskiy wrote:

[Lenny Soshinskiy]

If I understood you correct, actually there are some formats that are meant for what you said: .md (http://en.wikipedia.org/wiki/Markdown)
There is examle of Github supporting this documentation format https://github.com/nltk/nltk/blob/master/README.md
I would also like to state that XDXF as a dictionary format is designed to be as simple as it is possible for an attempt to code all dictionary sematics. BUT! it already becomes overgrown by excessive tags, which I'm not sure yet needed or not. So it will be a process of simplification, not otherwise.

Looking forward on your answer.

[Alex Enz]

No, Markdown is not that. I talk not about free formatting and natural langs. I talk about strict logical structure for reference books (encyclopedia, dictionaries and other technical and non-technical reference). Take into account that dictionary is a kind of reference. Every reference has list of word and articles tied to each word. Take man pages as a reference database. You type `man grep` and it shows an article for 'grep' page. If we talk about dictionaries for every word there is corresponding article with translation or definition. XDXF is best suited for dictionaries, but not for other types of references. Take as an example some technical reference. FreeType for example (http://freetype.sourceforge.net/freetype2/docs/reference/ft2-index.html). You can use HTML doc for this. But what about packing it into logical standard format, like XDXF for dictionaries. It will make possible to search for special reference page with simple util. This is what 'man' does. But,
1 'man' is relatively slow and not very suitable for really big references
2 It uses Roff language which is visual, not logical

Standard logical format will be very useful for technical programming references, among others. It's just about not to use PDF and HTML. It's about using 'man'-like CLI or GUI util for quick search.