xml-dev - Re: Syntax and Semantics

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

At 12:04 PM 5/19/00 -0500, Paul Prescod wrote:
>Peter Murray-Rust wrote:
>> 
>> ...
>> 
>> BUT it works for us. We accept all these failings. What pragmatic XML users
>> will not accept is being told that there is no way of carrying semantics
>> for XML files. Or wait 3 years while the name/use/mention/id/resource/label
>> problems are sorted out.
>
>I do not see the loading of a plugin for a mime type as a semantic
>boostrapping process. You are loading external behavior to go with a new
>data type. There are no semantics transmitted. 

OK. I expect that I have mis-used the term semantics - at least for part of
this community. I have assumed that in some cases *behaviour* is a way of
transmitting semantics, particularly for complex technical objects. Indeed,
apart from human-readable prose, it only seems to make sense to transmit
behaviour for some objects. I cannot easily see how we can reach semantics
for chemistry in my lifetime - indeed I am unclear what distinguishes
chemical semantics from chemical ontology.

>The browser does not
>undefstand what the SVG document *means*. It just knows how to display
>it.

True - but that is what I want to do with an SVG file. I am not sure what
else *I* could do with it. [I suppose I could see if it contained cyclic
graphs, but what else?]

>If you want to do anything else with it (e.g. edit it, transform it
>to CGM, store it in some form of graphic component database) you are
>probably out of luck because the browser doesn't know what the SVG
>document means. Plugins are about behavior, not semantics.

If I want to transform it to CGM I would use a set of rules. These rules
involve equivalencing concepts in CGM and SVG and creating an algorithmic
transformation. It is this transformation that I would see being
transmitted programmatically. [We need to do this for chemistry - I have
been thinking of this as mapping ontologies, rather than transmitting
semantics.]
>
>Plugins are great and important, but they have two problems which
>restrict their general applicability:
>
> 1. They each only really allow you to do ONE THING so the creator of
>the information must have pre-knowledge of what the client wants. "Oh,
>you want to show it in Netscape, so you need a Netscape plugin. And you
>want to convert it to CGM, so you need this XSL stylesheet that does
>that, and you need ..." The consumer is at the mercy of the producer.

Fully agreed. I know plugins are potentially evil. But namespaces only give
you one thing. They tell you that a given element won't clash with any
other element. 


I have been experimenting with Adobe beta(2) plugin for SVG Here are two
documents I have fed it:

foo.svg:
<svg>
  <g style="fill: blue;">
  <path d="m 0 0 l 0 100 100 0 0 -100 z"/>
  </g>
</svg>

This works great and draws a blue square. That is what I want. I assume
that the plugin picks up the file extension and/or the root <svg> element.

or 
plinge.xyz:
<blunge:svg xmlns:blunge="http://www.w3.org/TR/someSVGSpec/">
  <g>
    <path d="m 0 0 l 0 100 100 0 0 -100 z"/>
  </g>
</blunge:svg>

I have tried the second one with several guesses at namespaces from the SVG
specs. Every experiment gives me a blank white screen. 

The first approach is the "wrong way" but it works for thousands of people.
The second approach is - presumably - the "right way" and we are still
waiting for guidance as to how to make it work. Given that we have been at
it for 2 years, I assume it will take a bit longer. Meanwhile everyone will
be using method 1.

>
>
>> The immediate problem is the multiDTD file. We cannot use a single scalar
>> wrapper to describe the semantics. CML documents will contain CML
>> intimately mixed with SVG, MathML, XHTML, CALS/OASIS and 1-2 other common
>> technical DTDs. There either has to be a new wrapper specifying this or
>> there has to be semantics in the file. Either of these require the
>> browser-writers to agree on a common convention.
>
>Browser writers are the least concerned about semantics of all software
>engineers. They care about how things look. Database vendors care a
>little more. In theory, search engine vendors should care a lot more.


But it is the browser vendors who have brought us as far as we have come at
present.

>
>I don't think that what you want really requires a new specification.
>Browser writers could look up behavior for a namespace just as they do
>for a mime type. They just haven't implemented that feature! I don't see
>how more syntax in the document would help.
>
>Here's what I envision: the browsers would have a registry of namespaces
>just as they do mime types. 

I am happy for that. Is there any sign it is happening?

>Unlike mime types, the referent would not be
>a plugin but an XSL stylesheet. The XSL stylesheet could, itself, call a
>plugin/Java class/applet if it needed to do something more than XSL
>allows.

Yes. We already use this technology for sending chemistry over the wire:

http://www.ch.ic.ac.uk/chimeral

Michael Wright, working with Henry Rzepa and me has built an XSL stylesheet
which transforms an XML document (XHTML+CML) into various documents and
feeds them to applets. It does exactly what we want. We would be delighted
for the community to regularize something like this. But it doesn't work
through namespace URIs on the browser - the behaviour is hardcoded into the
stylesheet.
>
>It makes sense to default to XSL before Java/Active-X because it is a
>W3C standard, it is secure, it is not dependent on a graphical
>environment, it is supposed to be deployed in any browser that uses XML,
>etc.

Agreed.

>
>Namespaces are supposed to be the hook for both semantics (which are
>today transmitted in prose documents) and behaviors. Why add mime types
>to XML documents?

Mainly because:
	- the whole world uses them
	- any widely used MIME type has a high-quality prose description
	- they are simple
	- they are supported in mailers, browsers and other software

The challenge for the XML community is to elevate namespaces to this
position :-)
>

	P.


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************