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

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?

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?

This isn't just arbitrariness on my part. These 
are questions being asked very seriously in 
some quarters off this list, and they must be 
answered.  I can cite the SGML legacy, I can cite 
the lifecycle advantages (even where seriously 
compromised by well-formed approaches), but to 
make the case for a complete XML System in a 
world in which the proliferation of objects is 
fast and accelerating, we have to answer with 
something that is an irrefutable advantage.

I can cite one or two, but I am interested 
in what the list thinks.  I'm not looking 
to stoke the fires of paranoia, but I think 
there is a business case and it can't be made 
unless the technical details are understood 
just a little, and the technical tradeoffs 
are understood a lot.  Furthermore, unless 
one accepts and embraces the competitive position 
the adopter accrues, it isn't a very strong case.

With SGML/XML, the adopter can lay out a company 
that only knows how to do ONE DTD like filleted 
fish:  one slice/newDTD at a time.  But to do it, 
they have to dump the stylesheets and catalogs 
for most applications.  Ask yourselves:  when 
does it make good sense to have a stylesheet?

len

Received on Friday, 14 March 1997 15:02:32 UTC