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

[Feature request]: Provide a way to write note guid into exported .enex #66

Open
coldwinds opened this issue Dec 26, 2023 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@coldwinds
Copy link

coldwinds commented Dec 26, 2023

Suggestion

Note guid is an important information to identify a note, and good help to rebuild link relationship when a note have a link to another note, with guid in exported .enex for every note make it possible to rebuild the connection when import into 3rd party apps.

@coldwinds coldwinds added the enhancement New feature or request label Dec 26, 2023
@benjiwheeler
Copy link

Is there a place within a given .enex file that you think it would make sense for a guid to go?

@AltoRetrato
Copy link

One issue with this approach is that adding a new attribute to a .enex file, which is an XML file structured according to its DTD, could potentially make the file invalid in many programs. Some programs may not enforce strict DTD validation, allowing the modification. A workaroud could be using a modified DTD, but that may still cause compatibility issues with software that expects strict conformance to the original DTD.

I would also like to retain the GUID, and I thought it could be included in the <note-attributes> element, such as within a <note-id> element:

  <note>
    <title>[...]</title>
    <created>[...]</created>
    <updated>[...]</updated>
    <note-attributes>
      <author>[...]</author>
      <source>[...]</source>
      <source-application>[...]</source-application>
      <note-id>[...]</note-id>
    </note-attributes>
    <content>
      [...]
    </content>
  </note>

But I believe such modification should be optional in order to not break compatibility with other programs, specially when you consider that no program currently uses such data. And I think it would be easier to access the data directly in the en_backup.db SQLIte DB if you want to use it to export to other file formats.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants