Comments (5)
from tools.
from tools.
from tools.
I'm all for having a dictionary representation that is more strict. My hope was to maintain dictionaries directly in that format rather than having our dicts in generic TEI and converting to strict TEI. Is there any reason why we could not do that?
I would like to have diversity in dictionary applications and dictionaries rather than having a diversity of formats, each with a low number of applications. I'm also scared of debugging long conversion chains.
I have seen XDXF, but I didn't investigate it enough to see how well it works in practice. What would be the advantages over TEI? A stricter format definition?
It looks like they also don't have a single semantic format as a conversion target and rely on PyGlossary for other formats.
This discussion is getting a bit off-topic for this issue. Maybe we should split part of it off into a separate issue if there is interest in more discussion.
from tools.
This discussion is getting a bit off-topic for this issue. Maybe we
should split part of it off into a separate issue if there is interest
in more discussion.
The topic of the discussion seems to have become how to replace the XSL
stylesheets (or: how to write exporters). Which is what seems to be the
preferred solution to the original issue.
I'd say, we could just rename the issue.
Intertwined with the now-predominant topic is the question how strict
our format should be, and possibly, how it should be at all.
On XSLT:
- There seems to be consensus among you that it is not very well suited
here. - I just learned (a little) about XSLT.
- It looks close to functional programming, but probably harder to
use.
- It looks close to functional programming, but probably harder to
On IR:
- Already having only a single parser (constructing a common AST) would
be worth a lot. If redundant representations can be joined in an IR,
even better. - Parser + AST + IR could serve as an authoritative definition of
FreeDict TEI.- Currently there are:
- the Wiki: not exhaustive
- XML schemata: very large, hard to read (to me), not very
strict.
- Validation would come for free.
- Parser, AST and IR can be mostly self-documenting (and easy to
read).
- Currently there are:
- Ideally our format would be so strict that IR = AST (or at least
isomorphic, unless the IR is tailored to a target format). - One could add a pretty printer (IR/AST -> TEI). This should be
relatively easy.- This would help writing importers.
- If IR != AST, this would give us a way to translate any valid
TEI to a (to be defined) strict version. If we wanted to make
our format more strict, we could use this to transform existing,
less strict dictionaries.
On XDXF and Pyglossary:
- XDXF: Are we discussing whether to
- replace TEI with XDXF,
- use XDXF as intermediate format for exporting, or
- adopt XDXF's "approach"?
- What would that mean?
- If good converters from X to many other formats exist, it makes sense
to me to write a TEI to X converter with the intention to use those
other converters.- Particularly, if those converters are injective
(i.e., reversible).
- Particularly, if those converters are injective
from tools.
Related Issues (20)
- Use proper version numbers for WikDict dictionaries HOT 5
- [dict format] no dictionary title, 00-database-short missing HOT 1
- Executing teiaddphonetics without locale leads to problems:
- teiaddphonetics: espeak generates a newline on output for three dots of input HOT 3
- Extend tools to re-deploy dictionaries with a build number
- Rethink `build/tei` directory HOT 2
- Support StarDict format! HOT 27
- convert to csv HOT 7
- Teiaddphonetics fails to translate pol-rus HOT 1
- Use PyGlossary for additional export formats HOT 1
- teiaddphonetics fails on certain combinations of interpunctuation HOT 2
- teiaddphonetics: Add pronunciations to translations HOT 2
- imbalance: the build system requires dependencies that are not needed for simple tasks HOT 2
- Add a validate_all target HOT 3
- Extend FD-API schema to support full semantic versioning
- Teiaddphonetics: support XML includes
- xsl: teiheader2txt causes (non-fatal) errors on large input HOT 1
- fd-import version error
- eng-swe faulty pronunciation or text HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tools.