Another requirement qualification. (*Not* a proposal, please read!)
People don't seem to be interested in my project of listing
requirements, constraints and proposd solutions, but I will persist, as I
can no longer keep the proposals straight.
Point 1. of my requirements list gives the "desire that parse trees be
the same." Under that point, the following explanation should be added.
As Chris Maden has reminded us, not having this will break treeloc and the
untyped varieties of TEI extended location pointer, because sibling counts
will differ, due to pseudo-elements in element content. TEI typed pointers
are not affected, because you count elements of a specified type, and so
stray pseudo-elements would not be a problem.
So we need to add that as an important reason for requiring either
identical parse trees, or typed tree locations. It would really be a shame
if we define structural markup in a way that makes any class of structural
links _less_ dependable than byte offsets!
PS. I would welcome additions to the list of "proposed techniques" so that
we can understand the proposals.
I will repost the modified document and keep it up to date, if people will
contribute. At this point, I think everyone posting has made at least 1
different proposal, with various permutations of the same few techniques
and goals, and doubtless others that I have omitted. When there are too
many straw proposals, I think we must look to explicit goal-setting to make
I am not a number. I am an undefined character.
David Durand email@example.com \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________