Re: Trying to sum up a bit

At 05:24 PM 12/17/96 -0400, Murray Altheim wrote:
>I would hope we would avoid messy solutions AT ALL COSTS. The public view
>of XML will have a lot to do with how many messy solutions we create in the
>specification. Every instance of things like
>
>  <?XML-SPACE-PROGRESSIVE-SHIFT VARIANCE::8879-97//LPN SPIN-RIGHT="XML"/>
>
>as a learning requirement on document authors is going to hurt the
>perception of XML as a solid specification, free of hacks, and relatively
>simple to learn and use. I don't even like the opening PI much, to be
>frank. If option #3 only causes problems with 'certain HyTime addressing
>facilities', then it seems that someone should concentrate on coming up
>with a solution for HyTime, not XML. I wouldn't assume too many users
>coming up from HTML or learning XML as an 'onramp to SGML' are going to be
>impacted much by difficulties with HyTime addressing facilities.

As Eliot pointed out, HyTime is taking the rap for *all* addressing schemes
including the addressing schemes used in *all* style sheet languages. I
don't think it is esoteric to want to put a bullet on the first node in a
list item (and not others). I've had trouble with style sheet languages that
made that difficult or impossible before. Or to want every other node in a
list to have a dark background.

>If Jon is willing to admit to ignorance, I'll surely admit to plenty 'o
>ignorance. I don't even know what a HyTime addressing facility is, and I
>would hope I wouldn't need to know one from a Semantic Specific Result
>Instance, a Conceptual Output Instance, a Generic Language Translation
>Process Specification, a Formatting Output Specification Instance, or any
>other string longer than thirty characters. You won't find XML on any
>shelves if so. If someone needs this level of complexity, then, as we
>mention in the XML Q&A sheet, then don't use XML, use full-bore SGML.

Isn't XML supposed to be compatible with SGML? When an author decides to
start using his/her XML file as if it were "full" SGML, should they have to
rewrite scripts, stylesheets and hyperlinks? Just because of whitespace? The
fundamental question is whether the interpretation of the documents should
be different according to SGML parsers vs. non-validating parsers.

>>3. All non-markup bytes are signicant, whitespace or not (Durand)
>
>This is true only for the 'pGrove' (ala Kimber below)? In processing the
>pGrove, we make some assumptions about authors' intentions. Further
>processing is based on these assumptions:
>
>   a. whitespace within an element is significant to that element*
>   b. whitespace between elements is not significant

You <strong>can't</strong> <emphasis>do</emphasis> that. => You can'tdo that.

>   c. whitespace after a start tag is eliminated (ie., not significant)
>   d. whitespace preceding the end tag is normalized to a single space

I think that the other rules are okay, but the case of whitespace between
elements is common both in mixed and element content and authors mean
different things by it depending on the context.

>I must reinforce Jon's assertion that when discussing child nodes of a
>parse tree, most of us ignorant folks aren't going to be thinking of a
>linefeed as the third element of an ancestor.

Which is why we've got to get of that linefeed out of the parse tree. Rule
#3 puts it *in* the parse tree.

 Paul Prescod

Received on Tuesday, 17 December 1996 17:44:51 UTC