Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML API specification
 -----BEGIN PGP SIGNED MESSAGE----- Peter> Peter Murray-Rust <URL:mailto:Peter@u...> Tim> Tim Bray Tim> I would propose seriously that Java be the basis of the first cut Tim> at an API spec; it is really very pleasingly clean, and also has Tim> the virtue that ideas can be tested more or less instantly Tim> because there's running parser code to graft them onto. >>>>> In article <4028@u...>, Peter wrote: Peter> I'd agree with this. I think there is a case for a completely Peter> basic parser which builds from Lark/NXP and explores the basic Peter> issues that PhaseI raises. I think IDL is a worthy target, and one we ought to have in mind. But if speed of development and deployment are important (I think they are), a Java implementation makes a better "first-cut" prototype. Peter> The next question is the DTD. I create a DTD class Peter> (e.g. HTMLDTD, CMLDTD) whose role is to provide the information Peter> from the DTD to the application. I think this should be Peter> strightforward but I'm not clear enough to be sure what it Peter> should present. At present mine simply contains GIs (someone Peter> suggested ElementType was a better name.) It should also Peter> contain all the information in the normalised DTD, Peter> e.g. ContentModels, Attlists - what else is needed? An application may want to get at entity definitions (of both types). Certainly, in writing an editor-type application (i.e. anything which takes XML input, and transforms it into some related XML or SGML output), there's a case for preserving entity references, rather than expanding them. Something I'd like to do is to use Java as a kind of stylesheet mechanism, for interactive functionality not easy to do with DSSSL (which is somewhat paper-oriented). For example, I'd like to be able to write documents like > <?XML version="1.0"> > <?XXX codebase="http://www.ansa.co.uk/whatever/classes" > package="UK.co.ansa.tms" ?> > <!-- replace XXX above with the application's name --> > > <DOCUMENT> > <TITLE>Picture Gallery</TITLE> > <PICTURE title="My house" src="house.gif" thumb="thumbs/house.gif" /> > </DOCUMENT> and have the UK.co.ansa.tms.Picture class handle the rendering of the Picture element (I'd probably want a Default class to deal with elements that don't have corresponding classes - it would be tedious to write a class for every element). Ignore the fact that most HTML browsers can do something similar - in fact, one reason I'd want this is to have the UK.co.ansa.tms.Picture class generate HTML markup like <P><A HREF="house.gif" TITLE="My house"><IMG SRC="thumbs/house.gif" ALT="My house"></A> This mechanism would enable anyone to write XML documents and the Java classes to render them, if the receiver has the basic parsing engine - you could provide the same document with different classes for printing, for HTML production, for interactive use, etc - or your Document class may have interactive options (menu items) for these things, calling the appropriate methods in the rendering classes. Here's a rough skeleton: > package UK.co.ansa.tms; > > public class Picture extends Default { > // Default extends Component, for on-screen rendering > private String title; > > public Picture(xml.Element e) { > // or nxp.Element, or lark.Element - haven't read enough detail > // on either, yet. Can we have DTD information in e? > // Create from the parse tree > title = e.getAttribute("TITLE", true); > // We grab attribute values in their "cooked" state, after > // entity expansion > } > > public void draw() { > // called by the parent element > } > > public void print() { > // called by the parent element in response to user input > } > } That's a very simple class with empty content model, container elements would in most cases implement draw(), print(), etc. by calling the same method on each of their contained elements. An editing class, of course, may override routines for inserting or deleting content, or changing attributes. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBMxVzCedsuUurvcRtAQG4nwL7BXUR9R7UXfZZxTlb2AP6/vQjD4AdESiS YDyQEHZM4scfDwjkl2Y1RayRa4wHan3cmUBoRK+ooA87BCoVjsAO8Owphw6POYmK M7s96TG9CzEfxLPeu9Ju4UnBqVtiT2kS =A2u1 -----END PGP SIGNATURE----- xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
