W3C home > Mailing lists > Public > www-html@w3.org > January 2000

Re: OBJECT (was Re: So, what's left?)

From: Arjun Ray <aray@q2.net>
Date: Mon, 31 Jan 2000 20:26:58 -0500 (EST)
To: www-html@w3c.org
Message-ID: <Pine.LNX.4.10.10001312001580.15214-100000@mail.q2.net>

On Mon, 31 Jan 2000, Russell Steven Shawn O'Connor wrote:

> I agree that this would be ideal, but I have an itch telling me
> that the best solution somehow lies with the use of NOTATION.  
> But I'm not quite sure what that is.

Get with the program, dude!  NOTATIONs are SGML-geekery, and therefore
to be avoided like the plague!

But you're right.  NOTATIONs play an important part.  Unfortunately,
there's still a problem - something that spans all of SGML.  SGML has
no general mechanism to bind two notations (or two entities) together.
For instance, an ATTLIST for a NOTATION can't have attributes with
ENTITY or NOTATION declared values (the obvious way to do it.)  This
restriction was to prevent potentially unbounded chains of entity
dependencies - which ruled out the possibility of immediate dependency
too, unfortunately.  Removing this restriction didn't make it to the
WebSGML TC either.

This is important for <object> because it needs two NOTATIONs - one to
describe the object (i.e. the program implementing the notation) and
another to describe its inputs.  The normal SGML kludge was to do the
latter only, and conflate the NOTATION for the input with the program
that groks it.  That's fine if instantiating the program could be left
to system configuration, but not at all OK when it comes to having to
describe the program itself (or how to get it).  

So, there's a level of kludgery involved anyway (the problem is much
worse in XML, which doesn't have data attributes) - at least one of
the two ATTLISTs (for what are in principle NOTATIONs) will have to be
for an ELEMENT instead.  Since the properties of both code and data
will be <object> specific, this means one set of "arbitrary" elements
and/or attributes in the document instance.

We *might* solve that problem via architectures (i.e. require that
"definitional" element only to match a form) - but the W3C won't have
that either.  So, it's down to horsetrading and infighting over which
and how many attributes - 42?:) - for <object>.

Received on Monday, 31 January 2000 20:14:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:52 UTC