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

BTW, I agree with this completely.

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

This seems perfectly reasonable.
 
> I choose to use TEI for that because:
> 	- I understand it (unlike DSSSL)

Yes, but DSSSL needs introductory material.  If the SGML standard is not a 
resource for beginners in SGML, it is certainly not for beginners DSSSL--even
for experienced SGML people.  Hence, give it a chance once you get ahold
of introductory materials.
  
<snip>

> (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)

I not certain how Kawa plays into it, but I will say that it supports both
DSSSL quantities and DSSSL lambda procedures with keywords.  Thus, in some
ways, it is built to implement DSSSL.  We can all thank Per Bothner at
Cygnus for this.

> 	- our community will take years to write in it.

I don't understand.  Are you saying it will take *years* to write stylesheets?

> 	- they think that plugins and CSS will solve their problems anyway

Some, maybe, but it doesn't scale.  I'm both excite and disappointed about CSS.
CSS means I potentially can deliver SGML/XML to a standard web browser now.
It also means, I can't go as far as I need for some clients. 

I have people who absolutely *need* to deliver print documents over the net.  It
would be very nice to deliver a stylesheet that does that for them.  
Unfortunately, we have to do the formatting on the server and send them 
something like RTF or PostScript (preferrable the latter).

The other problem with CSS is the assumption that element equals style.  In
cases where style presentation is not a isomorphic relationship (that is
one-to-one and onto--a direct mapping), you can accomplish the style in CSS.
The "element equals style" concept can be severly limiting.  It also may work
just fine for your application.

Note: Any CSS people can correct me if I'm completely off my rocker.

> 	- it offers no functionality *after* parsing (or at least after
> 		rendering) as far as I can see.

What do you mean?  After parsing?

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

This can be done quite easily in a DSSSL system.  We do this now with our
product.  Every flowobject definition is dynamically loaded via class loaders
in Java.  Thus, definitions and semantics can be loaded dynamically.

> 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" :-).

Yes.  Absolutely.

In our DSSSL environment, first you compile the stylesheet with what is called 
a "flowobject registry".  The registry is responsible for delivering a
flowobject definition--possibly via loading a class of the network.  Then, 
when the document is formatted into a flowobject tree, semantics (classes) can 
be associated with each flowobject through the use of an exterior or an 
interior.  Hence, there is another set of classes that can be loaded.

So, similar to your questions above, we have located:

  * The style sheet.
  * The flowobject definition
  * The flowobject semantic

==============================================================================
R. Alexander Milowski     http://www.copsol.com/   alex@copsol.com
Copernican Solutions Incorporated                  (612) 379 - 3608

Received on Thursday, 27 March 1997 10:09:26 UTC