[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SOX
At 07:30 01/10/98 -0700, David Brownell wrote: >In the list of antecedents, let's not forget IBM's XML4J >which has an "element factory" API for creating specialized >elements. Totally agreed. I should have included xml4j in my list of element-oriented approaches - I just haven't played much with xml4j. And this emphasises the need for creating as much communality at present. My main motivation is to be able to write things like MoleculeNode.class that can rely on a core XML implementation to manage all the non-domain-specific stuff. (I don't actually *enjoy* hacking namespaces, etc. every time they change :-). I'd hate us to get to the stage where we have applications which have to be labelled 'only processable with xml4j... xml-ea1 ... xxx ... jumbo' because we all used different interfaces. Of course there is a level at which we move from an OpenSource-like set of APIs and supporting code to manufacturer-specific toolkits, but I hope we have still a long way to go in the OpenSource direction. >Some of my current thought: > >- To the extent that we're talking about actual components > we are language-specific (preferably Java :-) but it could > be useful to think a bit more generally. Agreed. > >- I'd prefer to name element types as { namespace uri, tag } > rather than with compound strings or a flat namespace. I think this is critical. Every time I now come to an elementName I groan internally ("do I need to support namespaces at this point?"). I feel held back in some things I want to do because if I don't get it right it will cause pain later. > >- Issues include how to construct a given node, and (IMHO) > the desirability of specialized parse-time interactions to > affect/approve the tree(s) constructed. 'approve' means a form of 'validation'? - it seems a useful word. > >- Depending on special DTDs or DTD rules may be unwise in > the general case, and even in the typical one. > >- Most non-structural operations should be separated. For > example, GUI stuff should all be separate interfaces. Some > attention to delegation will be important. I think most of us would agree on this separation. And I suspect that the non-GUI stuff may be a good place to start. > >- Generating customized content. It's no good solving only half > the problem, and customization during parsing is "easy" (as > suggested by all the results there). Could you expand on 'customized content'? Does this mean creating element-specific storage and additional methods? > >- Separating configuration issues (property file vs a more > structured XML file vs compiled in defaults vs inferring > mappings from packages, etc) from everything else will help. > A factory API helps a lot here. > >Clearly, I agree this is important. Very pleased to have your contributions. 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
|