Re: ERB meeting, 30 October 1996

At 06:49 PM 10/30/96 -0800, Joe English wrote:

>The /> NET trick is extremely fragile.  Most current
>SGML parsers cannot even implement it, and those that do
>cannot enforce its proper usage.  

Huh? Define "fragile" please. This usage of NET is precisely in accordance
with the definition of NET in 8879, and is therefore only fragile to the
extent that ISO 8879 itself is fragile. It is seems obviously not true that
"Most current
>SGML parsers cannot even implement it" -- any parser supporting SHORTTAG
and delimiter changes in accordance with the standard already *has*
implemented it. Even a parser that fails to support the delimiter change,
though it should be fixed, will at worst be off only slightly: it will
recognize the slash NET and then leave an extra ">" as content: at least it
didn't trash the tree, say by leaving the element open for ages.

What do you mean by "cannot enforce its proper usage"? This could only be
applicable to something that must write out XML; but we covered that by
allowing the <e> form, which I think is what any conforming SGML system will
write out for empty elements.

>...If a user forgets to
>supply the correct SGML declaration, SGML parsers will
>still accept XML documents *but will interpret them incorrectly
>without even issuing a warning.*

True, but if the user forgets the SGML declaration for *any* SGML document
that changes it from the RCS in the slightest way, it will fail (reportably
or not, but it will fail). I hope we're not thinking of ruling out all other
changes from RCS (like, say, limiting GIs to length 8!) to protect users who
forget the SGML declaration....


>Another problem with the /> NET trick is that it's *still impossible
>for a structure-controlled application to create a parseable
>instance from ESIS*.  This is one of the more serious problems
>with ISO 8879 from a tool-writer's standpoint; this is an issue
>that XML *must* address for it to satisfy design goal #9:
>"XML documents shall be easy to create."

If this is a serious problem with *8879*, there is not much we can do to fix
it in XML; or am I missing something?

Received on Friday, 1 November 1996 10:45:00 UTC