Re: Re Stylesheet association
Terry Allen 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
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
> | 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
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?