Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added handling of structured content for edition values. #54

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

ukretschmer
Copy link
Member

This enables the creation of structured bibl-elements, e.g. to set a reference to an external source for online and hybrid editions.

It is possible to either set structured content directly in the edition column in the csv file or by setting a structured content as title within the ini file.

See ini and example files in examples/shorttitle-replacement.

This enables the creation of structured bibl-elements, e.g. to set a reference to an external source for online and hybrid editions.
@rettinghaus
Copy link
Member

This opens pandora's box. One key feature is that CSV2CMI always produces valid CMI. Allowing XML as input would break it.
Also the output won't work, as the target attribute does't work (see example output). I would prefer to parse the string and tag an URL.

@ukretschmer
Copy link
Member Author

Related to Your second statement: The structure parsing didn't work for ini file template, because I used a non-existing replace function. It does exist in lxml.etree library, but that's not the one we are using here, so I fixed that by commit ecccc23. Now it works or what did you mean with the target attribute example? In my case the whole xml structure wasn't parsed.

@ukretschmer
Copy link
Member Author

According to Your first argument. Yes, You are right, it is a kind of opening this popular box, but

  1. There is no need to use this feature so basically the tool is safe and delivers valid CMIF.
  2. It is a kind of expert mode for users knowing what they are doing. If I write XML I am responsible for what I am writing, not the tool. So if I produce an invalid bibl subtree, it is my fault.

Your suggestion of parsing and linking URLs is safer on the one hand, butt less flexible because the link content always equals the link target. That's not what I need for my usecase, doing something like:

URN: urn:nbn:de:bsz:14-qucosa2-77749

What do you think?

@ukretschmer
Copy link
Member Author

While thinking about that, what about allowing kind of markdown link syntax in edition title, like [TEXT](URL). This could be parsed safely to <ref target="URL">TEXT</ref>.

This is definitly safer, but again, also less flexible. It addresses link integration in bibl, only.

@rettinghaus
Copy link
Member

We're trying to establish a standard with CMI. So from my point of view the bibliographic entries should comply to a standard too, preferably ISO 690. And as there are no universal resolver for URNs, this also should always be a complete URL (e.g. see here).

This all refers to these:
TEI-Correspondence-SIG/CMIF/issues/8
TEI-Correspondence-SIG/CMIF/issues/14

I thought about markdown, too. But still, a plain <bibl> should always follow some citation style and has to be plain text. With markdown you have no choice, but to process it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants