XSL and the semantic web

[David Brownell]

"Simon St.Laurent" wrote:
> 
> At 09:21 AM 6/16/99 -0700, David Brownell wrote:
> >And one more:  you appear to be assuming that the client actually
> >has enough horsepower and information to do the transformation (or
> >for the FO side of the argument, formatting) ... those are known
> >to be false assumptions in many cases.  A PDA with a typical speed
> >IR link (not measured in megabits), slow CPU, and small fixed size
> >storage just doesn't have that kind of resources.  For many set-top
> >boxes, ditto.
> 
> Maybe it's just that I'm at JavaOne, where Sun and 3Com keep talking about
> what you can do with Java on a Pilot, but I see the bandwidth as more of a
> problem than the processing power.  It might well make sense to create some
> kind of PDA middleware that slims down content before shipping it to the
> PDA, but that seems more a matter of consumer-oriented content-negotiation
> than producer-determined semantic firewalling.

Well, I was one of the first folk to publicly articulate that
particular strategy on JavaSoft's behalf (almost two years ago
now!) so I'm well familiar with the notion.

But I don't see ANY difference betwen that and semantic firewalling.

After all, isn't "content negotiation" just saying "firewall me
away from these sorts of semantic I can't deal with"?  And isn't
the firewalling you object to just the provider's constraints
showing up in the negotiation?


> >If the semantic content is a "web" then anything short of looking at
> >the whole web at once (yeah, right!) is looking through a "firewall".
> 
> In all of these cases, I have a very simple question: do you want to be
> able to choose the level of semantic information you receive, or do you
> want that to be determined by your provider? 

Yes.  The provider must of necessity choose how to respond to
my particular choice.  If I don't like that response, I can
choose to request a different "level" (or probably "type") of
information.

This isn't an either/or question, and there are a variety of
reasons providers may not be permitted to share certain data.
Privacy guarantees are one example (financial, medical, etc),
but aren't the only one by far!

If the original content has data that isn't allowed to be shared
except in "aggregate", then there may well be legal firewalls
in place.  There's a huge web ... and nobody has more than one
little window onto it.


>	 I have no object to
> intelligent content-negotiation. I do have a problem with handing content
> producers new tools for creating dumbed-down content with XML, the very
> language that was supposed to improve the level of information quality on
> the Web.

"Improve" is a standard that different folk apply differently.

For example, if I manage an account database, it's an "improvement"
to me if I can use the "Extensible" Markup Language to share parts
of it, for use in particular workflow processes.

If I understand things, you're saying at one extreme that providing
preformatted data (e.g. FOs to render a report) is a Bad Thing.  And
at the other extreme, maybe, that sharing anything less than the whole
content of an account record is also a Bad Thing.  In both cases the
"client" should make those choices.

I guess it just comes from my perspective in systems design, but I
just can't accept that clients "should" be that smart.  If I provide
a report on a delinquent account, I don't want anyone else to be able
to hide important bits so they can claim in court that they didn't get
notice.  If I share data with a partner, I may want to limit the amount
of analysis they can perform on that (to protect my business).

How much work to put on a client and a server is always a tricky
issue, but it's safe to say that for every task that _could_ be
offloaded from the server onto a client, there will in some cases
be nontechnical policies (legal, business strategy, etc) forcing
them to stay on the server.  Ditto technical ones, as in the example
I gave of clients that are too low-powered to do the work.

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)