Re: SOX: was Re: XML and Objects
Thanks very much - these are very much among the sort of questions that I expect we shall need to address. At 21:46 01/10/98 +0200, james anderson wrote: >Peter Murray-Rust wrote: > >a number of things re "XML and Objects", and closed with the suggestion that >it would be useful to focus the discussion on a set of questions. >Although I am not the right party to moderate (I'm working in a different >language, so the compatibility issues are academic), I would like to point to I don't necessarily think we are limited to Java, though I think that will be the main thrust. From my perspective the client gets at XML element and needs to do something with it. There is no requirement that a particular element is always treated by the same code, any more than (say) there is a universal HTML client. >several essential questions which I have not yet seen addressed in these >terms, as I would hope to see them resolved by whatever process develops. > > >1: >I have found it straight-forward and sufficient to identify the element type >through the simple mechanism of class-name lookup. Note that I am working in Remember that the client simply has an element name to start with. They have to be able to identify a class (regardless of language to associate with it). This could be a planet-wide piece of Java (e.g. org.xmlcml.MoleculeNode.class for element ("http://www.xml-cml.org", Foo)) or it could be a locally mounted 'helper' application - the element is mapped to C:\bin\rasmol.exe. Either way we need a mapping. Some people have suggested mappings are very difficult. I'm more optimistic! > >In a CLOS environment, this depends only on a mechanism which identifies lisp >packages with xml namespaces. For java, by analogy, a mechanism which >identified java packages with xml namespaces would suffice. > >2: >Since, for my purposes, type and storage are both identified with the class in >CLOS, the storage structure is identified through a mechanism identical to >that used for type - class name lookup. Because of my approach to 4 and 5, >this simplification is reasonable. I suspect that in the first instance the storage will depend on the implementation of the processing code. That may be able to offer options (e.g. persistence) but people like me just want to start with something that works for simple cases and build up. > >3: >This is a much stickier problem. As I have followed the discussion, most of it >has implied that one and the same instance serves to model both the object >which was encoded in XML and the application's view of the related (or even >identical) object. I recall only one note which suggested an alternative, that >a standard element class model the element specific behavior distinct from >application specific classes. I would second this notion. In other words, the >XML instance is a model of the application instance for the purpose of >encoding it in a serial stream. I am not quite sure I understand this, but I would agree that the XML is an abstraction of the instance as far as possible. In my own field (molecules) I expect radically different implementations to view and process the same instance since people have different views. (e.g. benzene rings can be represented with single/double bonds or with aromatic bonds). I think this is more than just a style issue. > >4: [beyond me :-)] > >5: >For reasons analogous to 3, I find it sufficient to leave untouched the >DOM(-equivalent) storage model which is sufficient for element instances. >Application specific storage requirements are handled in the autonomous >application specific instances. For many objects I would wish storage which was different from the DOM or SAX representation (e.g. for efficiency of storage). Thus a molecule with 10^5 nodes is very inefficient if stored as nodes, but can reasonably be input and output as such. But I may have missed your point :-) 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto: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