Lists Home |
Date Index |
Patrick Durusau writes:
> Yes, and the ambiguity solution inherited from SGML was to solve the
> problem in syntax, not in the processing layer. Since the ambiguity
> problem was solved by Earley in 1970 (Earley, J. (1970) An efficient
> context-free parsing algorithm. Communications of the Association for
> Computing Machinery, 13(2):94-102) as well as dealt with in NLP and
> other disciplines by techniques such as active chart parsing and parse
> forests, I fail to see any reason to continue to with a solution in
Since I'm not familiar with that algorithm, and I have little
understanding of computerized natural language processing, could you
explain this? The information I can find on it suggests an algorithm
that's at least beyond my ability to implement - lookahead and
probabilities are definitely not my specialty.
I'm not sure that a "solution in syntax" is necessarily a bad thing,
though I'll readily admit that it's not an optimal solution for many
> The "inline" vs. "out-of-line" distinction does not bear close
> examination. All "out-of-line" markup does is move the tree syntax
> problem one step away and allow you to have one more tree for that a
> particular text. The NLP community can hardly advise speakers/writers
> to move ambiguous text "out-of-line" and hence must parse it "inline"
> where it occurs.
For NLP, you may be correct. I suspect there is a class of problems for
which out-of-line markup approaches and multiple overlapping trees is in
fact a good idea, but I certainly won't claim that class includes your
set of problems.
> I see the "out-of-line" solution as more of a hint
> as to the underlying cause of the problem than a solution.
I think the distinction between inline and out-of-line raises a set of
issues that can inform the practice of those of us who generally find
the inline style of XML to be useful.
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!