Re: XML Conformance Levels [Was: ERB Decisions of March 26th]

In message <199703270933.JAA25814@curia.ucc.ie> Peter Flynn writes:
> > > O goddess, please not. This is in jest, right?
> 
> Murray writes:
> 
> > Nope. But what's the alternative?
> > 
> >       XML-CORE:    fully supported or no support at all
> >       XML-LINK:    fully supported or no support at all
> >       XML-STYLE:   fully supported or no support at all
> >       
> > Now really sit back and let that sink in a minute. If you want to develop
> > an XML processor/application, you either support CORE or not. Fine so far.
> > But if you want *any* linking or stylesheets (and you can't approach HTML's
> > functionality at all without both) then you must implement both *completely*.

I don't see this follows necessarily.  I do not - at this stage - intend to
implement stylesheets at all, but I do intend (within my technical limitations
and an unknown final draft) to implement LINK completely.  I have implemented 
TEI though I will have to extend it (if not in XML, then at application
level). [I need to be able to search numbers, chemical formulae, etc. after
retrieving 'resources' via TEI.]  I am working on what I believe to be a 
'link processor' for JUMBO, though I'm not yet clear precisely what the spec 
demands.  

The reality with JUMBO is that I want to 
(a) implement XML-CORE completely.  The only sensible way is via NXP/Lark.
(a1) implement some application functionality (e.g. editing, browsing, 
rendering, etc.) on top of XML-CORE.  We all agree that that is my business -
if it's reusable by other members of the community, great.

(b) I want to have the whole of XML-LINK.  Whether I do depends on whether
	- I am capable of doing it all in Java
	- someone else writes reusable components for TEI and/or LINK
(b1) I want the client-side application to be able to search documents/objects.
I choose to use TEI for that because:
	- I understand it (unlike DSSSL)
	- it does (most of) what I want.
	- it might come for free as a reusable component
	- it will have wide currency.
I will, at least, have to have an application-specific method for extending 
the TEI addressing.  FOREIGN seemed obvious and very cheap, but I've had my say.
(b2) I want to implement robust hyperlinking.  I will use XML-LINK (I am
taking it on trust that the ERB knows better than I do what I need :-).
The latest draft about Xptr is precisely what I want, for example.)
However, I may fail in my ability to implement links, and my application
will simply say to the user "sorry, JUMBO is not clever enough to support
this feature".  I suspect we are going to see a good deal of that :-)

(c) I have no obvious need for DSSSL.  There are several reasons:
	- it will take me 2-3 months to understand it and see if Kawa or
		similar is useful to me.  (Scheme is a non-starter, sorry)
	- our community will take years to write in it.
	- they think that plugins and CSS will solve their problems anyway
	- it offers no functionality *after* parsing (or at least after
		rendering) as far as I can see.
(c1) I believe we can solve our 'style' problems by supplying methods attached
to elements/objects.  I may well be wrong, but it works so far.  For example,
I have taken Jon's PLAY and hacked a very few classes which render it 
appropriate styles.  Thus there is a PERSONA class which draws a little icon
and changes the font.  Where appropriate it uses TEI notation to identify
components to process.  I doubt there is much more code than DSSSL equivalent.

The key question which I hope XML-WG/ERB will answer is "how do I specify
whcih version of a class to apply to FOO?"  That seems to me to be isomorphic
with "which style sheet containing FOO shall I use?" and *possibly* "how do
I get it" :-).

It is possible that this question will be answered under XML-LINK rather than 
XML-STYLE since it could be thought of as 'behaviour'.  If so, great! :-)

	P.

-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

Received on Thursday, 27 March 1997 08:12:20 UTC