xml-dev - Re: (off-topic) Re: Recursive Children?

[Rick JELLIFFE <ricko@geotempo.com>]

Joe English wrote:
 
> Actually no: '#CONREF' *only* means that "if this attribute
> is specified, the element to which it belongs must be empty".

Except that CONREF means "Content Reference", does it not?

The name is the primary indication of the driving intent, not the
syntax and not the property set. In the same way, "attribute" and
"element" do not refer merely to information items in different
delimiters: the differences in the meaning of their names indicates 
something about them even by setting reasonable expectations
(i.e., the expectation from the names should reasonably be that
an attribute will be information about the element as a whole while
an element in content is merely some part.)

Otherwise, SGML is turned into merely a mechanism for data
manipulation rather than being an implementation of a particular
software engineering strategy.

> The intended semantics is that the application could generate
> content for the element (in some unspecified way), but the parser
> doesn't do anything else with #CONREF attributes.

Sure, an application can do that. 
 
> > That allowed
> > SGML to specify many-to-one relationships on "children", but it wasn't
> > used much because most SGML was stream-processed.
> 
> Attributes with declared value REFID turn into an 'irefnode'
> property in the grove, not a 'subnode' property; and the
> presense of an attribute with a #CONREF default value
> only ensures that the parent node will have _no_ 'subnode'
> property (or an empty one, I'm not sure which, but it
> amounts to the same thing).  So the "children" relation
> always forms a tree, not a DAG or cyclic graph.

Yes. By quoting "children", I was trying to distinguish it from normal 
children or subnodes.  It would have been clearer without the 'on
"children"', but I don't know what else to use. (But note that SGML'86
implementations do not have to follow the ISO property set specs to be
conforming.)

Rick Jelliffe