Re: Entity and Element Addressing

   >What are the advantages to relaxing this restriction?  And if there
   >are lots of others who agree with Gavin on this, speak up. - Tim

     1) It allows you to use entities, even when you don't have a
	declaration subset or DTD.
     2) It can help to reduce packet sizes in a realtime environment.
     3) It can make it easier to generate content dynamically.

Whoa. Pin (3) up on the board and ring it in red. Remember all the
FAQs to the HTML WG and elsewhere asking why HTML didn't have an
<INCLUDE> and we all said "but SGML _does_, just the browsers don't
implement them". This is a Selling Point.

   >My conception of Well-Formedness has always been along the lines of
   >"you can build the right parse tree".  

I'm not sure about "right" yet: doesn't well-formedness mean you can
build _a_ parse tree, deduced (in the absence of a DTD) from the
symmetry and nesting of the markup? I'm sorry if this was thrashed to
death before I came in, but it's one of those things we are going to
have to be utterly unambiguous about.

   >Now, we have partially ducked
   >that by saying that you don't have to fetch & parse external text entities;
   >but you do have to know what the reference is pointing at.

Do you mean...?

      "I have to be able to resolve the address implied by the
       entity reference even if I don't go fetch it now" 
or 
      "I have to know what kind of object this purports to be, 
       even if I don't go sniffing at the address right now"

The first means more cycles at parse time; the second means authors
will have to type their links.

   My ideas for entity resolution were posted long ago to this
   list. Basically, if all else fails (ie. no catalog, no declarations),
   then I would like to see clients looking for "foo" or "foo.xml"
   relative to the URL of the referring entity. A little extra robustness
   and flexibility.

How I wish current SGML software did the same :-)

///Peter

Received on Wednesday, 29 January 1997 16:22:27 UTC