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

machine-readable DTD #8

Open
rwb27 opened this issue Sep 19, 2017 · 4 comments
Open

machine-readable DTD #8

rwb27 opened this issue Sep 19, 2017 · 4 comments
Assignees

Comments

@rwb27
Copy link
Contributor

rwb27 commented Sep 19, 2017

It would be good to have a formal specification for the XML format - the readme file doesn't define everything, and can't be validated by XML validation tools.

@MakerTobey
Copy link
Member

MakerTobey commented Nov 6, 2017

Richard, you have written one, right? Can we add that to the meta repository and start maintaining it? It looks like there will be some XML extensions coming up soon with new collaborators.

@rwb27
Copy link
Contributor Author

rwb27 commented Nov 6, 2017

I've not - while I have now reworked all the XML parsing code I didn't write a schema. That said, I probably could do without too much trouble...

@MakerTobey MakerTobey added enhancement help wanted compatibility Making DocuBricks convertible into other formats and removed compatibility Making DocuBricks convertible into other formats enhancement help wanted labels Apr 19, 2020
@MakerTobey
Copy link
Member

I wonder if this has already been solved by proving definitions
here https://www.docubricks.com/software.jsp
and also here: https://opensource.ieee.org/docubricks-maintainers/docubricks-standard
A validation tool sounds very useful in particular to validate the format after document modification in other tools (e.g. as Markup in GitLab).

@rwb27
Copy link
Contributor Author

rwb27 commented Apr 20, 2020

Those pages do give most of the information required, but it's not complete - the advantage of a formal datatype definition is that it will force you to specify, for example, which things are attributes and which are sub-tags (those pages don't specify it, and I tend to refer to your typescript parser when I'm looking for that information).

While it's tempting to go for the more readable-looking bullet points that you have, the (admittedly much less attractive) formal specifications are really useful to anyone else looking to work with the format. Of course, you probably want both - but if the friendly description is generated from the formal one, you can be sure that it's consistent and accurate.

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

No branches or pull requests

3 participants