XSL and the semantic web

[Marcelo Cantos]

On Thu, Jun 17, 1999 at 07:43:54AM -0700, David Brownell wrote:
> Marcelo Cantos wrote:
> > 
> > On Wed, Jun 16, 1999 at 09:21:48AM -0700, David Brownell wrote:
> >
> > > 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".
> > 
> > I'm a little confused, and I think it relates to a degree of confusion
> > between formatting and transformation (XSL/XTL?).
> > 
> > My understanding is that Simon et al object to the use of server XSL
> > to provide formatted output to the client.  Paul suggests that this is
> > a good thing because it gives the owner of the data choice in what to
> > make available to the user.  David then provides some examples to back
> > up this argument.
> 
> Actually, I gave more general examples too ... when you transform the
> data in any way (not only turning into "formatted" output like HTML,
> FOs, etc) you may be preventing "clients" from seeing data that some
> may want to be able to see.

I still don't think this is the point.  If one has:

  <employee status="active" security="high">
    <name>Joe</name>
    <phone>555-12345</phone>
    <home-phone>555-55436</home-phone>
    <salary>$30,000</salary>
  </employee>

Then the following two transformations:

  <employee status="active">
    <name>Joe</name>
    <phone>555-12345</phone>
  </employee>

  <H3>Joe</H3>
  <P>Phone: 555-12345</P>

Are of a fundamentally different character.  It is not a simply case
of having more or less information.  In the second example, even the
structure of the information you are entitled to (and this from the
owner's viewpoint) has been lost, and gratuitously so.

FO's leave you with what might as well be a GIF rendition of the
information you are after (indeed, GIF may well be safer, since one
might be less tempted to be naughty and make assumptions about the
structure of the FO output, such as "Phone number is after the colon
in the first <P>").  A qualified FO:

  <DIV CLASS="employee" status="active">
    <H3 CLASS="name">Joe</H3>
    <P>Phone: <SPAN CLASS="phone">555-12345</SPAN></P>
  </DIV>

would certainly go some way towards easing the strain though I don't
know if typical FO models (XSL in particular) allow this much
flexibility.

> > My problem with all this is that the cases-in-point that David
> > supplies (embedded systems notwithstanding, though they really are a
> > separate issue in my opinion) are all more appropriately dealt with by
> > transforming the data rather than formatting it (in fact, David even
> > refers to it as such).  But this is not, as far as I understand it,
> > what Simon is objecting to.
> 
> I see all of those transformations as points on a spectrum, and the
> note I responded to didn't seem to be restricted to XSL FOs; it didn't
> mention FOs or formatting, as I recall.  (I was concerned about whether
> the discussion lost some context, too!)

Granted, it is a little difficult to know where the volleys are going
(or, for that matter, coming from :-).

I have to take issue, however, with the characterisation of the
transformations as points on a spectrum.  There is a very well defined
distinction between transformation and formatting within the XSL
model, hence the move to split it into two separate standards.  I can
see how, in the general sense, there might be a continuum, though I
was addressing XSL specifically, so perhaps we, too, are talking at
cross-purposes!  :-) :-)

> Turning data into presentation-only data is just another transform, in
> any case, for all that it's a bit more apparent how much was removed.
> Clients don't generally have any "right" to see that extra data.


Cheers,
Marcelo

-- 
http://www.simdb.com/~marcelo/

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)