Stream: IG creation
Topic: page.generation code
Eric Haas (Jun 08 2020 at 20:10):
I noticed the following issue:
when xml page in the ig resource page.generation code is defined to be "xml" not "html" which is opposite of how the ig-pub is implemented.
e.g., input/pagecontent/file.xml i for the ig resource needs to be :
- nameUrl: file.html
title: File
generation: html
I think this error is confusing to have the xml and generation different, but not sure whether is worth correcting the ig-publisher or change the definitions.
Lloyd McKenzie (Jun 08 2020 at 22:32):
The requirement is that the content is XML (specifically XHTML). Regular HTML is not allowed.
Eric Haas (Jun 09 2020 at 00:54):
the code definitions do not match how is implemented in the ig-pub
should be
xml files = generation: xml
html files = generation: html
Lloyd McKenzie (Jun 09 2020 at 03:21):
There's no such thing as html files as input - it's either markdown or XML
Eric Haas (Jun 09 2020 at 03:48):
Lloyd McKenzie (Jun 09 2020 at 03:53):
The templates don't allow html - all page content needs to be xml (i.e. an XHTML div) or a markdown equivalent. A full XHTML page wouldn't let us assert headers or footers. It's possible that someone outside of HL7 might create a template uses those, but they can't be used in HL7 IGs. I'm not understanding what the issue is?
Lloyd McKenzie (Jun 09 2020 at 03:54):
We put .xml files in the input folder. We call them .xml in the build
Lloyd McKenzie (Jun 09 2020 at 03:54):
Ah, never mind. I see the concern.
Lloyd McKenzie (Jun 09 2020 at 03:55):
Yeah, wouldn't be bad to fix that, though it'll break everyone's IGs...
Grahame Grieve (Jun 09 2020 at 03:58):
I'm not following the issue, but waiting won't help with that, so we need to decide now
Lloyd McKenzie (Jun 09 2020 at 04:11):
In the IG, when content is XML files (i.e XHTML Div elements rather than stand-alone pages), the IGPublisher is expecting the declaration to be "html" instead of "xml".
Lloyd McKenzie (Jun 09 2020 at 04:12):
We could just update the description of html and yank xml and say that specifying full-blown web-pages isn't allowed. That'd be the minimal impact on everyone...
Eric Haas (Jun 09 2020 at 04:19):
or allow both xml and html...
Lloyd McKenzie (Jun 09 2020 at 04:35):
No reason to have 2 codes with the same meaning
Grahame Grieve (Jun 09 2020 at 06:22):
well, technically, there is a difference in the allowed entities, but otherwise they are not different
Chris Moesel (Jun 09 2020 at 12:43):
You could allow both xml and html for now, but issue a warning when people use html when they should have used xml. This would give them time to transition before their builds break -- and then after some time you could remove it and just cause a hard error.
Lloyd McKenzie (Jun 09 2020 at 14:13):
Base question: Do we want to allow full HTML pages (no standard header, footer, etc.)?
Jose Costa Teixeira (Jun 09 2020 at 14:47):
where would we want that? having an html page in the ToC would bring a user out of the navigable content, no?
A elsewhere-defined HTML page could could be added as a href in the menu.xml, no need to bring it in via the publisher...
Eric Haas (Jun 09 2020 at 16:38):
I think this was originally a Lloyd feature ;-)
Lloyd McKenzie (Jun 09 2020 at 16:40):
Nope - I never brought across plain http pages
Eric Haas (Jun 09 2020 at 16:46):
anyway... it was in the orginal config files. I don't care either way .. never used it
Last updated: Apr 12 2022 at 19:14 UTC
