xml-dev - XDEV proposals (was Re: Recipes for Information)

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

At 01:06 22/11/97 -0800, Mark L. Fussell wrote:
>
>This is somewhat related to the recent threads on Integrity and 
>Inheritance.  It is again a bit long so it will be duplicated at MONDO 
>(www.chimu.com/projects/mondo).

Thanks Mark - extremely valuable.

[... long insightful and stimulating discussion snipped ...]

I think I understand the wishes of  Mark and an increasing number of
XML-DEVers and hope the following is useful...

I come from a non-SGML background and have discovered the formal
limitations of SGML/XML in what I want to do. [The DTD doesn't map onto my
problems, no datatyping, no easy extensibility through inheritance, etc.]
As Mark says, the background of XML is paper-based (and this is reflected
in XSL which is essentially paper-based with very small concessions to
paper-like screen display). Nevertheless the DTD-based approach is
extremely powerful in the right cases and in the right hands.

The problems I address have the following generic operations.
	- I want to author XML. Ideally this should be human- and
machine-readable. I want this process to be controlled by software/data to
make it both flexible and rigorous. [This is tough, but I'm starting to
address it in JUMBO. Practical help will be appreciated :-)].
	- I wish to be able to re-use other people's information objects. This is
almost certainly going to break any DTD, but it is implicit in most of the
current W3C activity. (RDF, MathML, XSL may have some sort of DTDs, but
they will probably be used as components of larger documents, which cannot
have DTDs)
	- I wish to be able to manage distributed and multicomponent objects.  I
think XML and related disciplines will solve this very well and excitingly.
	- I want to be able to validate XML 'objects'. XML can do this
syntactically, but not semantically. For this I need additional 'recipes'
and code
	- I want to be able to transform XML objects into other XML objects. XSL
is tantalisingly close to being able to do this but I believe - at present
- that W3C XML-transformation activity is 'undefined'.
	- I want to be able to send XML objects to other people *with* a prior
contract as how these are to be used. XML can partially solve this at
present using DTDs, controlled prose and vocabularies and *bespoke
applications* (i.e. a different application for each DTD.) This is as far
as X*L goes. Much of the X*L prose stresses that particular activity is
left to the *application*. This means that XML documents often need to be
authored, knowing what application is going to be used to process them.
This is, presumably, the way that CDF is designed - you have to have a 'CDF
processor'. However it does not support *generic* applications (or even
generic components of applications).
	- I wish to be able to send hypermedia. XLL specifically declines to add
any semantics to the syntax, other than an (implied) HTML-like behaviour
for some of the SIMPLE links.
	- I wish to send objects to other people who will print them out and read
them. XSL solves this.
	- I wish to be able to send XML objects to people who I don't know  exist,
have never heard of me or my domain. [Example, a supermarket may need to
hyperlink to molecular information in labelling its food products.] They
need to access my semantics in (a) human-readable and (b) machine-readable
form. For this a *generic* XML processor (or processing component) is
required. This *is* achievable (through XSL) if the processing activity
consists of producing 2D human-readable objects. I, and I suspect many
others, want to be able to create generic XML applications. [JUMBO is a
*generic* XML application - it can process any XML document. The degree of
added value depends on the components made available by the document's
author or domain.]

Most of these issues are not being addressed, and probably will not be
addressed by the current XML activity. [Not a criticism - they are doing a
fantastic job. Their time is taken with deciding on precise syntax,
procedures, meaning of components in XML documents, etc. More difficult
than I think a lot of people realise.]

This is where XML-DEV has a role to play. Not formally - this list has no
standing other than the high quality of its postings. Since many of these
areas will give rise to 'colliding ontologies' (i.e. strongly held views on
how to do things and what things mean) there are no single solutions.
However, if we treat this in the spirit of a biological system, 'fit'
solutions should arise. 

To be 'fit' a solution must:
	- reproduce readily. IOW it must be relatively easy to understand what
it's about. Simplicity is very valuable here :-)
	- be useful.
	- have a modest degree of flexibility. Too much variation kills off
complex organisms.
	- be aware of its environment. If it's competing in a niche which is
already filled, it will have a hard time. i.e. if you haven't looked in
other disciplines, you will probably reinvent something.

[The biological metaphor isn't worth elaborating :-)]

My hope, therefore, is that we can identify and systematise certain areas
which are useful to a group of people. [There may be multiple and
incompatible solutions - so long as they are identifiable that need not be
a problem.] Among the *simple* ideas that might be tractable as XDEV
proposals are:
	- parser APIs and the generic behaviour of applications. Whatever happened
to Xapi-J?
	- datatyping
	- re-usable elements, probably with machine-readable schemas.
	- transformation language (this *might* spare us from my Monty Python
proposal :-).
	- behaviour for XLL-based applications

If you do take these ideas up, please use simple subject lines :-)

	P.

>
>
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)