Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML API specification
 Toby, Your suggestions are very similar to my own way of thinking, and what is implemented (very crudely) in JUMBO. In message <s867zebhm4.fsf@p...> Toby Speight writes: [...] > > 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. My gut feeling is that if we pursue a Java implementation then (apart from the speed - which matters to me :-), we shall create a namespace that is reusable by the IDL. It may be that this has to be expanded but that's not a problem. > > > 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. Totally accepted. (The sort of thing we might want to do is to create a 'ThesisEditor' for chemistry. This would have entities like &chapter1; &tables1; &molecules; etc. and these should be relocatable as entities as well as expanded subtrees. > > > 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 ^^^^^^^^^^^^^^^ Agreed. > 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 Exactly. This is my DrawableElement class - it can be displayed, but probably only offers a subtree, attlist, PCDATA children, etc. in a standard fashion. > 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. > Exactly. Your document is WF (it doesn't have a DOCTYPE) but the author is saying "I have used a PICTURE tag. I suggest you retrieve the Picture.class method and apply it. Here's an address you might use (www.ansa.co.uk...)." The client doesn't need to know what a Picture is. IFF you agree with the client what a Picture is, the client might say "thanks, but I already have client.Picture.class and I'll use that". client.Picture might be a subclass of ansa.Picture. This is the Java equivalent of applying stylesheets at different times. > > 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. This is exactly what JUMBO does - every Element has a display(Graphics g) toString() toHTML() toSGML() // should be XML :-) debug() process() // for delayed processing and caching of complex Elements mouseUp(...) etc. addHelp() // element-based help drawIcon(...) // icon-based recognition of element One obvious example of a re-usable Element is DATE where the pointer can be to java.util.DATE. In that way we could use 8601-based dates and render them interactively. Other examples would be things like the various image types. With a WF document you have to be careful that the client picks up the right class and you have bound this via the APPLET mechanism. With a non-html-based document there needs to be some way of locating the methods precisely. You also have to download information for each class used. You need to have a mechanism for loading the classes (i.e. something has to recognise the ElementType and download the class, maybe creating an Element of this subclass - this is what JUMBO does.) A Valid document can also use the DTD information and in that way can pre-load the appropriate classes. It may also help to create a robust type of distribution, especially where the DTDs are accepted within a community and signed classes can be installed on the client side. [...] > P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ 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
|
|||||||||
