Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SOX: was Re: XML and Objects
 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 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. > > ... > > When a Document is created in the DOM the elements are of identical class > (ElementNode?). SUN and JUMBO add a layer where subclassed objects are > generated according to the elementName (and possibly other criteria). These > objects may have further methods for display and non-display purposes. If > we are going to have interoperable software then this is an area we should > regularise ASAP. > > [ contrast SUN and JUMBO2 ] > ... > > When I create MoleculeNode I endow it with JUMBO methods and therefore it > doesn't interoperate with SUN. I would be delighted to agree publicly on > how to do this now. If we leave it we shall be too late and we shall have > applications-specific )and possibly platform-specific element-oriented > programming. This would be very sad. There are several issues here 1. How to identify which behavior to associate with the element identifier? 2. How to identify which storage structure to associate with the element identifier? 3. Which behavior (DOM and/or application object model) is associated? 4. How is the behavior implemented? 5. How is the storage structure implemented? 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 CLOS, which has a MOP adequate to this purpose. Pre-namespaces I had tended towards an index of dtd/document specific class definitions. With the advent of qualified names, and with the presumption, that definitions used in one document for a unique name should agree with those used for the same name in another document, the per-document qualification is superfluous. In the cl-xml implementation the element identifier simply denotes a symbol. An optional attribute permits instance specific variation. The symbol, in turn, names a DEFCLASS'd class. There is a safety check to ensure that the proper interface is supported, but the basic rule is: if the symbol names a known class, then the element is intended to encode the named class. no tables. no props files. 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. 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. 4: Issue 3 carries over to the approach to 4 and 5. That is, in most cases the implementation implied by the discussion to date is that inheritance be used to achieve an identity between the element and the application instance. In the alternative note, I recall the suggestion being that a delegation relation extend from the element instance to the application instance. As I have come to understand XML as an encoding standard and not a modeling standard, these suggestions surprise me. Of the three possible forms a. identity between application and encoding instances b. encoding instance delegates to application c. application instance delegates to encoding the latter makes more sense for complex applications. For example, aspects of behavior may not coincide or may vary depending on the encoded content. This means, that a more complex translation process may be necessary in order to decode to the application model than would be appropriate to model in the DOM or its descendants. In some cases, I have found it advantageous to accomplish the translation functionally. In CLOS, the method definition mechanism offers the advantage that it is possible to specialize on multiple arguments. This means that it is possible to define a "translation application" which comprises an application instance and a collection methods which are specialized on the combination of element class and translation application. I have found this degree of specificity to be useful when decoding complex data structures. In the encoding direction, on the other hand method 'c' can be specified fairly directly in the class declaration. 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. 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
|
|||||||||
