Flare adds a d1p1 namespace - why?
Posted: Tue May 30, 2017 3:57 am
I have been working on a Flare project (not one I created) in which one of the source files has the following opening element:
After a bit of investigation, I found that Flare inserts the d1p1 namespace declaration and attributes if the default xmlns:MadCap value is wrong. This is the case here - note the spurious spaces either side of the MadCap schema URI.
Has anyone else had this happen to their files? I'm curious as to why this namespace gets inserted.
You probably wouldn't notice this issue unless you've tried to process Flare source files with a script. This is what I did, and the script (in Python) didn't consider the file valid XML. (This wasn't an error in the script - it was thrown by Python's core XML parsing module.)
I did a web search on "d1p1", and it seems to be a namespace that is generated automatically by some applications. It's not unique to Flare - seems to be something to do with .NET.
It's not an issue now - we've simply corrected the MadCap namespace in the source file, and deleted the d1p1 references - but I'm curious as to what d1p1 is, and why it stopped Python from parsing the file. Any suggestions?
Thanks,
Franky
Code: Select all
<html xmlns:MadCap=" http://www.madcapsoftware.com/Schemas/MadCap.xsd " MadCap:lastBlockDepth="10" MadCap:lastHeight="3677" MadCap:lastWidth="644" d1p1:lastBlockDepth="10" d1p1:lastHeight="313" d1p1:lastWidth="650" xmlns:d1p1="http://www.madcapsoftware.com/Schemas/MadCap.xsd">
Has anyone else had this happen to their files? I'm curious as to why this namespace gets inserted.
You probably wouldn't notice this issue unless you've tried to process Flare source files with a script. This is what I did, and the script (in Python) didn't consider the file valid XML. (This wasn't an error in the script - it was thrown by Python's core XML parsing module.)
I did a web search on "d1p1", and it seems to be a namespace that is generated automatically by some applications. It's not unique to Flare - seems to be something to do with .NET.
It's not an issue now - we've simply corrected the MadCap namespace in the source file, and deleted the d1p1 references - but I'm curious as to what d1p1 is, and why it stopped Python from parsing the file. Any suggestions?
Thanks,
Franky