Tim Bray wrote:
> The kind of argument on the WG that would succeed in swinging me
> (and I suspect a lot of others) toward including FPI's would be a war
> story along the lines of "here's how we used FPI's to solve important
> problem X, and here's where you can go and look at the software that
> does it." Of course, the software function would have to be something
> that you could do in a lightweight, compact implementation.
I think a concise statement of the problem FPIs are intended to solve
and a shorter primer of how they do that would be invaluable as well
because otherwise, they really do look like an overbuilt lookup.
Because the URC came up in another post, I recall a lot of discussion
on the syntax issues of using SGML for that. Many of the arguments
were based on parsing problems in SGML, the speed of value-pairs vs
1. Might XML help in the parsing problem of the URC?
That isn't a work item here, but I am curious because
a lot of work went into the Dublin core, etc.
2. Are the implementation problems of the FPI related to the
parsing difficulty, the resolution, interoperation with other
resolution components, what? James? (saying it takes 5000
lines doesn't help me understand why it takes 5000 lines).
- Re: FPIs
- From: Tim Bray <email@example.com>