xml-dev - Re: Syntax and Semantics

[Paul Prescod <paul@prescod.net>]

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. The browser does not
undefstand what the SVG document *means*. It just knows how to display
it. 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.

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.

 2. It is difficult to make them a) secure, b) efficient and c)
effective/powerful/flexible. So an Active-X control has properties b)
and c) but not a). An XSL stylesheet has property a) (we hope!) but b)
and c) are questionable and so forth.

If you had transmitted all of the semantics (a dubious prospect, IMHO)
the *client* could invent and apply any behavior it is interested in.
Because I understand your message there are an infinite number of ways I
can work with the ideas in it (including replying, passing them on,
rewriting them, merging them with mine) You didn't transmit behaviors to
me -- just the ideas. I think that only inferntial beings can do this
but I have very little knowledge of AI so maybe computer inferencing is
farther along than I think.

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

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

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.

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?

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Just how compassionate can a Republican get before he has to leave the 
GOP and join Vegans for Global Justice? ... One moment, George W. Bush
is holding a get-to-know-you meeting with a bunch of gay Republicans.
The next he is holding forth on education or the environment ... It is
enough to make a red-blooded conservative choke on his spotted-owl
drumstick.     - April 29th, Economist

***************************************************************************
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/
***************************************************************************