Open alfsb opened 1 day ago
Typo fixed, also fixed an error condition. Two follow ups:
Suggested convention for XInclude xml:id
s: {parent_id}..{local_xinclude_id}
I was experimenting with some reserved syntax for xml:id of includes, but as xml:id are NCName
, their contents are severely restricted. I was worried about classes between structural ids, auto generated file ids and the new XInclude ids. But after a while, I got that any current id "reserves" a namespace of sorts, so using a convention like this will avoid collisions.
So in the examples above, the xml:ids created for XInclusion would be like function.fgetcsv..parameters..separator
. This avoids collisions and also has a nice property of indicating where the referenced id is being defined, if some XIncludes fail (to help translators).
Suggested convention for XInclude <xi:fallback><!--doc-en-fatal--></xi:fallback>
Speaking of failures, the other follow up is that <xi:fallback>
presence effectively disables detecting XInclude failures. Tolerating XInclude failbacks is important for translations, but is a hard error on doc-en
. So I propose another convention. On XInclude call
sites:
<xi:include xpointer="function.fgetcsv..parameters..separator">
<xi:fallback><!--doc-en-fatal--></xi:fallback>
</xi:include>
So that in the XInclude fixups, it would be possible to detect and report XInclude failures, and also make it fatal again on doc-en.
Instead of <!--doc-en-fatal-->
, other suggestion is <!--xi:fallback-->
, as no "xi:" is expect to survive $dom->xindluce()
.
Scratch the thing about doc-en-fatal
. The last commit added automatic xi:fallback
for all manual!
<xi:fallback/>
can be removed completelydoc-en
are hard errorsFor example, an XInclude like this:
<xi:include xpointer="nothing"/>
Is reported as:
Failed xi:include at: /set(index)/book(appendices)/appendix(ini)/section(ini.list)/para/table/tgroup/tbody
Failed xi:include target is: nothing
This PR includes a fixup step on
configure.php
XInclude processing, to the effect to simulating XML Inclusions Version 1.1.With this PR, an
doc-en
manual with this changes builds ok:The
xi
prefix or..
separators are not special. They are only a suggestion for a convention for these structurally incorrectxml:id
s, but the code works perfectly ok with any xml:id.This will also enable putting some of
language-snippets.ent
entities that are tightly related to an extension, and XIncluding these "hosted" entities directly from their extension related xml:id.Fun fact: The PHP manual has ~25.000 IDs at XInclude processing step. Inspecting they two times in a row takes almost no time.