Menu
▾
▴
#370 system entities vs. XInclude
closed-accepted
2
2012-09-20
2012-07-24
No
While statements such as "[the TEI] makes use of entities, an almost obsoleted feature of XML, that originates in SGML" (source unnecessary) need not be taken seriously by those in the know, they have an unpleasant ring to them and the first part (the statement of fact) is easy to verify, while the second (the underhand pinch) is easy to accept for people new to the scene.
This is a request for some of us to find the time and/or occasion to review the changes that moving from system entities to XInclude would involve.
Does the indirection provided by the current system: declaration (in guidelines-en) + invocation (in the particular chapters) give us an advantage over XInclude statements?
If, instead of:
<!ENTITY model.entryLike SYSTEM "Specs/model.entryLike.xml">
...
&model.entryLike;
we do just:
<xi:include href="Specs/model.entryLike.xml" />
... and remember to pass "--include" to the parser, do we lose any control/validation over the included fragments?
It may be that in some cases, the automatic validation will not expand the includes and signal OK even though the include will be invalid. That, however, can be easily controlled, and one can argue that the option not to expand the includes may be an advantage sometimes.
Moreover, it may be easy to make a pass across the Guidelines with XQuery or XSLT (and --include switched off) to prepare a map of inclusions. That is harder to do in the current system, where the parser doesn't see the entity invocations by definition (you'd need Perl or something like that).
Have I overlooked something serious?
Well, the floor is open for discussion.
This seems sensible to me. I'm wary about changing our setup too much, but I have always felt that this use of entity references should be deprecated. I would be interested from an assessment of sebastian and martin to see how much work they think it would involve in changing our processing chain.
assigning to rahtz to get his attention.
use of XInclude limits the software which can be used to process the source, as everyone understands entities but not everyone understands XInclude. It seems to me that XInclude has not been a very successful thing, so I am a wee bit wary.
i dont think it will make writing tools any easier or harder.
I have a feeling that eg jing's XML parser does not understand XInclude?
but what the heck, yes, its perfectly doable. might need some directory reorganization, will need some changes to the Makefile.
is it worth it, though? if it aint broke, etc.
I took a look at roma2.sh, and I see a lot of this:
xmllint --xinclude
where I was actually expecting
xmllint --noent
If we're not already using XInclude, what is that doing there?
I don't share Sebastian's wariness with regard to XInclude. The basics of it seem to be working fine with tools such as xmllint, and the basics are all we need here (include a complete file at this point). Fancier stuff would be nice, and eXist for instance provides it (you can XInclude a sequence of nodes based on an XPath), but for the purposes of Piotr's ticket, XInclude is fine I think.
This isn't about the Guidelines -- we only talk about the issue in the intro to XML (see http://www.tei-c.org/release/doc/tei-p5-doc/en/html//SG.html#SG-mult which you might use to rebuff this ill-informed criticism if you like) but rather about our own internal workflow producing them. As such my personal view is that it aint broke and we have more important things to spend our resources on than fixing it. Have recategorised this ticket accordingly.
I am mostly inclined to agree with Lou about the "if it aint broke" viewl;
however, we do expose our source tree, and we have been pillored in public
for using entity refs there, so I claim there is a case to answer.
Council thinks this is a generally good idea but a very low priority. (At Oxford face to face meeting 2012-09)
this has now been done. may take a few tweaks to finish off working, I will watch out for these.