Re: Re Stylesheet association

On Mar 14,  1:51pm, Len Bullard wrote:
> Subject: Re: Re Stylesheet association
> Terry Allen wrote:
> >
> >len wrote
> >
> > | object encapsulation, virtual interfaces, etc. are used,
> > | you can't and that is exactly why some will prefer to do
> > | this.  Inheriting the interface, not the implementation,
> > | and hiding the implementation is key to distributing
> > | objects without giving away code.  I guess what I am
> >
> > So far as I understand what you're saying, such an arrangement
> > would rely on the user already possessing some sofware that
> > encapsulates the semantics of the XML.  Is that right?  If so,
> > that software already has the information about what tags are
> > EMPTY.
>
> Depending on the level to which they hardwire the app, yes.
>
> Would you rather send an encapsulated object down the wire,
> an application --,  (what an instance plus processing specification,
> plus any embedded thingies, plus PIs which hide the DTD under
> smokin' syntax are), or just a data file of hierarchies of
> value-pairs?
>

Depends entirely on the circumstances.  Sometimes you need to send an object
because you are trying to convey behavior which doesn't exist at the client
side.  Sometimes you send "data" because you are trying to convey information.

It is very much a question of semantics, because (unlike an XML document)
objects _are_ semantics - they provide a particular "interpretation" to strings
in the language specified by their interface (incidentally, Alan Kay has told
me this was very explicit in the earliest versions of Smalltalk).

In their cdf specs, Microsoft adopted XML because it makes no sense to send
objects - how the information is to be used is a client concern (and don't you
think they'd use COM if they could?).  There will also be cases where the
server has already sent info to personalize the client, so all it is sending is
information to previously downloaded objects.

> > | saying is, some people think the way to maintain
> > | proprietary code is to encapsulate and deliver only
> > | exposed information.  I think we shall see a lot
> > | of applications where XML is just initialization
> > | data and the stylesheets are irrelevant.
>

This will certainly be the case.  Here, XML is just a convenient data
structure. But my favorite examples are where information may be handled in
ways the server knows nothing about.  I think object interfaces, since they are
naturally going to revolve around behavior will always be limited - they can't
anticipate all they ways they will be used.

> This is the key.  It is the key to what Eve is suggesting
> about PIs, about the question Tim passes from the
> conference about "selling a million units", "competitive
> advantage", semantics vs data, etc. etc. etc.
>

Semantics vs. data is real important.

> Push aside the syntax arguments for awhile.  Forget
> URLs.  Forget stylesheets.   Why would one want to
> use XML and StylesheetX if all they have to do is
> deliver an object to the user and the object is
> automatically usable?  It is complete, it is ready
> for action, it's interface is already contractually
> obligated.  Why?
>

And it is totally limited by the vision and economies of scale (one can only
program so much functionality) of its creator.  XML data will be much less
limited and far more easily integrated into _other people's_ applications (and
even my own).

> If I want to add an object to an Active-X system,
> right now, I just have to keep up with COM.  As
> long as the IUnknown and queryInterface pointer
> magic is done right, it will work.  Every time.
> If apply containment and aggregation correctly,
> I even get a pretty efficient system.  If I
> keep in-process, out-of-process, and remote
> process interfaces (stubs, etc.) straight, this
> all even works across a network transparently
> except for speed.  Why bother with XML, HTML,
> SGML, or DSSSL?
>
> Keeping up with a complicated packaging
> scheme, stylesheets, collections, catalogs,
> and the other nine yards looks pretty daunting
> to someone who only has to submit to COM/OLE
> to get what they want?  Right?
>

Isn't this a case of intuitive really meaning what you're used to (although
your basic point still holds)?

However, I've got to agree that the SGML community has built a complex array of
standards and terminology parallel to what the rest of the world is doing.  It
may be better, it may be worse, but it's still pretty daunting.

At the same time, I think we've been a little overly nervous about sending DTD
information.  I suspect that people are thinking of Docbook or HTML DTDs, but
many applications will have DTDs that are just a few lines long.  I mention
this because well-formedness will not always be sufficient for the client - it
needs to know that at least a part of the document is valid, or that the part
of the DTD it is interested in conforms to the one it knows.

Matthew Fuchs

Received on Friday, 14 March 1997 17:16:53 UTC