Re: Stylesheet association

Matthew Fuchs wrote:
> 
> > 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.

Right.  In some cases, all you are sending is the information needed 
to initialize objects, things that already have class distinctions.  The 
property values can be validated as long as the types are known or 
determinable by DTD or "hey, I'm a Doc of this type".  I note the 
CDF example includes the doctype.

> 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).

I think it is still explicit.

> 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?). 

I think they do.  I think they use XML because they need an analogus 
fat packet to formatec.  They don't send the object; we have the 
object if we are using a CDF client.  That's the point.  That's also 
why XML is valuable beyond practice.  If one competitor can only 
use One DTD and refuses to use others, the easy way to corral them, 
shear them, then blood them is to put out a lot of little DTDs 
with the code.  Make it easy by the DTD and the editor to 
enter information, and force the other guy to cope.  NEVER 
use the stylesheet because that exposes the code.  The DTD is 
cheap to write; the code is expensive.  ALWAYS hide the implementation.
Use the *standard approach* like a skillful filleting knife.
The ironic thing is by claiming HTML was a standard, its 
supporters handed them the knife.  XML makes it into stainless 
steel;  it stays sharp.

> 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.

Downloading is not the issue.  How they got the objects isn't important; 
only that they have them and can read the initialization data:  eg, the 
well-formed instance Plus whatever else it needs.  PIs/DTDs add more 
initialization data or data for the object to munch on.   Packaging 
and marshalling start to look a lot alike.
 
> > > | 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. 

Not convenient;  strategically deadly.  Now that they can extend, 
extend fast while the other guy is still trying to convince 
everyone else not to do it.  The fight is won or lost in the 
first six months.  It uses the same colonization approach and 
exploits the other guys lack of vision.

> 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.

Ah, but how often will that be the case especially for 
well-formed instances?  IOW, when do we not  
know semantics in advance? If we don't is it cheaper to 
send the objects/semantics, then begin sending the data to 
munch as needed?  Or, in short, how often would I 
want to send a stylesheet, and why would I want a 
stylesheet if I can send an object?
 
> > 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.

Duh.  It's data AND semantics with a separation 
made for convenience of transport, particularly, trying to 
get the size of the rat the snake is swallowing down...
or network packets.

> > 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).

No.  A COM object can increase its functionality at any time 
using dynamic marshalling.  The creator only has to rename 
the interface, and the receiver's system can install it and 
use it without the client even knowing that is done.  COM 
handles versioning.  A data format can only accomodate 
so much reuse.  There is a sliding scale between two poles.
But at least, it can be adjusted.  There is a choice.
 
> > 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)?

No.  This isn't intuition at all.  It is an economy of interaction, 
or communication.  If I send you (client) an object ready to 
go, why would you want to do the assembly yourself?  Why not just 
query for the interface and let me (server) do my work.

> 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.

Sure.  Well, what I am getting at is the plea "keep this simple". 
We have sort of, but we may by adding lots of PIs, stylesheets, 
catalogs, etc. be about to repeat the old madness because that 
is what we understand.  There may be cases where the old 
madness is warranted, but we better be very clear about what 
those cases are or the business case for XML is nil or at 
least, exactly the same case as SGML.  XML becomes "a rolling con".

We didn't make things better; we shuffled all the pieces, fixed empty
tags and 
end tags, and agreed on how we want to do strongly typed links.
That's a lot for SGML, but may not be a valid business approach 
when one can buy into COM/OLE and skip a lot of this.  We can 
say we've reached "critical mass" but that's not just silly, 
that's laughable.
 
> At the same time, I think we've been a little overly nervous about sending DTD
> information.  

Yep.  Given everything else we have to package, that is trivial.

>I suspect that people are thinking of Docbook or HTML DTDs, but
> many applications will have DTDs that are just a few lines long.

Yep.  A lot of us championing DTDlessNess are the same people who 
championed some of the most overbuilt DTDs ever seen.  IOW, a neatly 
circular and self-fulfilling prophecy.

>  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.

Yes.  Then there is the question that if we are adding lots of PIs,
templates 
whatever to get around the DTD, why not just send the DTD?   At least
that 
is well-understood if not well-formed practice.

len

Received on Friday, 14 March 1997 18:20:09 UTC