Re: ICADD support in XML [Was: SGML declaration for XML]

> At 03:37 PM 11/11/96 -0500, Steven J. DeRose wrote:
> >Insisting that vendors implement LINK in order to support ICADD is the
> >surest way to be sure no one implements ICADD, which I think would be a
> tragedy.
> 
Alan Karben wrote:
> I'm still ramping up on these issues, but I would venture that XML offers a
> much better solution than the current ICADD for those who need ICADD's
> benefits.

You might well be right.  One discussion was about the use of LINK
for adding ICADD SDA forms to the HTML 3.2 DTD.

I am still not convinced that this is a good idea.
As far as I know, none of the major HTML browsers today will cope very
well with an SGML declaration in a document, let alone a link process
definition.  Presumably <!USELINK...> would become legal within an HTML
document.

Introducing LINK into HTML could have interesting implications for
CSS1 and also for anchors -- it gives you a way of doing something very
like a HyTime ILINK (but restricted to pointing to entire elements).

But given that HTML applications today don't (in generl) even support
document-specific entities, it would seem to me better not to extend HTML
in this way, but to use existing technology.

If you want to have the ICADD attributes in a separate file, assume that
the SGML 97 rule has passed to allow
    <!AttList X
	a "b" #IMPLIED
	percy (x|y|z) "x"
    >
    <!AttList X
	c "d" #FIXED
    >
so that you can put all the #FIXED attributes (and maybe others) in
a separate file and include it from the base DTD.

Alan's comment:
> Doesn't the world of style sheets offer a far greater avenue for opening
> access than hiding hints inside a DTD? Instead of just prefixes and
> suffixes, a content provider could call for much more useful
> annotations/transformations/inflection-changes.

Is a good one.

LINK was an early (and I think unsuccessful) attempt to provide a
general transformation model for SGML.  This has since been done
in DSSSL.  It would be better to supply a DSSSL transformation than
a LINK process definition set file, I think.

It is unlikely that existing vendors will start to support LINK.
It is very likely that they will support DSSSL.

On the other hand, as far as I can tell from reading 8879, an
SGML application can ignore LINK if it wants to.  The information is
a hint to the parser, no more.  I don't have a formal definition of ESIS
in front of me, so don't know if ESIS is required to be changed by LINK.

So maybe HTML software could conform if it ignored the LPD.
But I am not sure if that helps anyone.

Since the issues are political and not technical, I don't think I
can comment further.

Lee

Received on Wednesday, 13 November 1996 22:21:25 UTC