Re: Object-oriented serialization (Was Re: Some questions)
David Megginson wrote: > How does the schema tell me that foo represents a container for a > collection of objects, bar represents an object, and hack and flurb > represent the object's properties? The point is not what the current schema draft allows, it is whether it would be feasible and appropriate to represent this information in XML schemas, as Paul rightly stated. My opinion is that it would be fairly trivial and extremely useful. > It can be. The DOM represents a domain-specific object layer that is > useful for a wide subset of XML operations (especially document- and > browser-oriented work). There need to be many layers on top of XML, > one for each domain -- it happens that many of those layers will share > the need to encode objects, so a standard object layer sandwiched > between XML and the domain-specific layers can save a lot of work. Sure, the DOM has value. My point is that maybe 95% of applications want a domain-specific rather than a generic interface. My other point is that a domain-specific interface can be implemented generically; i.e. programmatic interfaces for accessing XML data can be generated automatically from XML schemas. This isn't *that* far from what MDSAX is doing. IBM's XML BeanMaker (http://alphaworks.ibm.com/tech/xmlbeanmaker) is a good example of this concept. > > There are a variety of efforts to create > > domain-specific objects automatically from XML objects. I don't have a > > list at the tips of my fingers, but if anyone does it would be a great > > resource. They are out there because I keep bumping into them. > > One example is RDF. So we are talking about different things. RDF is a formalism but it doesn't provide you with any code (although I'm sure that tools for this could be written, and perhaps already have been). I am talking about something that will take my schema with Customer and Invoice element types and turn it into, say, Java classes called Customer and Invoice. > I disagree strongly with the last part of that statement. I'd argue > the opposite -- higher-level layers should be as independent of XML as > possible. That's the only way to build good, layered architectures. > XML does one thing (represent a tree structure in a character stream) > very well: it's an excellent layer to build other layers on top of, > but XML itself should stay as simple as possible so that it's > applicable widely to many different fields. I agree with the layering approach. But well-formed XML should be viewed as the lowest level (representing tree structures); when bound to an XML schema it then becomes a serialized object representation. > That would be another serious mistake. Object exchange, while > important, represents only one of many layers that can be build on top > of XML, and if XML Schemas start trying to solve high-level problems > for every specific domain, it will become an unimplementable mess. > RDF already made a similar mistake by mixing together a spec for > object encoding in XML with a spec for representing knowledge about > Web pages. Maybe this is the crux of our disagreement. I see object exchange as *the* application for valid XML. I'd be interested to hear some examples of applications that cannot be cast effectively in this light. In this view, RDF and XML Schemas are coming at the same problem from different angles. RDF is saying essentially "how do we build an XML application that represents object structures", while XML Schemas are saying "how do we enhance DTDs by adding some object-oriented facilities". My fear is that these two approaches are going to meet somewhere in the middle and turn out to be the same thing. If so, I vastly prefer the use of XML schemas. Why? Because this results in a vast simplication of the whole XML picture. Isn't it better to take a normal XML instance, using base XML syntax, and "turn" it into an object by adding the appropriate information in a separate schema, rather than having to recast the whole thing in a different syntax? (I wonder if I am expressing this idea clearly. I'll happily post an example of how this could be done if I'm not.) Cheers, Matthew 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/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe 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