Re: B.9 Formal system, public identifiers?

>>I disagree. Using FPI's and FSI's for naming is simple enough.
>
>I just counted the number of lines of code in the part of SP that handles
>external entities; I included just the URL and OSFILE storage mangers, and
>just the UTF-8 and Unicode encodings.  It was more than 5000 lines.  I don't
>see how we can possibly meet our goals for ease of implementation if this
>part of XML has this level of complexity.

I think the figures depend largely on how much code reuse is in effect.
Most people dealing with XML probably already have code to use. For those
that don't, I don't see 5000 lines of code as a major overhead, because
the code is very straightforward. One other thing: any XML applications
that try to do anything even slightly complex will require entity
managers. by stating up front what the overall functionality is expected
to be, people can design the entity managers with the future in mind.

>Don't get me wrong: I love FPIs and FSIs.  But I strongly believe this whole
>XML exercise is going to be a total waste of time unless we exercise extreme
>self-restraint in the features we put in XML, especially in version 1.0.

I agree with you wholeheartedly. The real thrust I've been continually
trying to make is that of building a good infrastructure that is
open-ended. As such, I see nothing wrong with using FPI's and FSI's,
possibly with some constraints (XML 1.0 only *requires* certain forms
of FSI). The constraints can be removed over time, but the foundation
cannot be relaid time and time again.

Received on Tuesday, 15 October 1996 15:37:55 UTC