Missing preflight publication check

[jkiddo]

The website.url in the publication-request.json may not shade across the destinations.

if it does the publisher acts in mysterious ways

• add to that - ... it works fine for the first publication ... but once you are doing your second publication it starts acting up

also stated on https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Second.20publication.20goes.20bad.20.2E.2E.2E.20.3A.28

[lmckenzi]

@jkiddo To confirm, the issue is that website.url is defining a 'root' url, but you may have destinations in your publication file that are not proper descendants of that 'root' url -and if that happens, the publisher doesn't behave properly. And you're advocating that the publisher should check that all destinations are in fact proper descendants of the root url. Is that explanation correct?

[jkiddo]

The destinations should be relative (adding) to the root url at all times. Current behaviour is inconsistent as it seems to be a mix of both relative ( destinations) and fixed ( root ). If the root is x.y.z and the destination is 'z', then the clean end result should be x.y.z.z - or it should fail fast. Right now it fails very late in the process.

[jkiddo]

To be clear: I dont want x.y.z.z. I wanted an error saying that 'z' was shading over the root url as it was x.y.z where it should have been just x.y - and I would prefer to have that error early.

[lmckenzi]

We should be spitting out a warning or error if the canonical is not the same as the url + destination.

[jkiddo]

On this one I would prefer a fail-fast