Re: More namespaces (non)perversion
Ron Bourret wrote: > However, somebody (Bill LaForge?) thought that this stuff probably shouldn't go > in the schema file, as it is application-specific, not schema specific. That > is, while you would presumably have a single schema for a given document class, > you would probably have multiple bindings. (Please correct me if I've gotten > this wrong.) I've certainly said as much in a number of presentations: the association between these "XML Beans" (XObjects) is a function of the task being performed with the data, not of the data itself. Some have called that "subject oriented" computing. It's an old and well proven model. Most people see it in terms of connecting different languages together via data format specs. That's not the simplest model though, and many folk want simple models to use (start with, evolve from, etc). Hence the recurrent desire of many folk to have a schema support stuff like this -- they've heard of schemas, schemas are new too, so just group it all together. > Of course, there's nothing to stop you from naming bindings and keeping multiple > different binding sets in a single schema file, but at some point I have to > wonder why you need the schema information at all. Does an application that > uses element bindings also need the other schema information, such as content > model and attributes? It strikes me that the application generating the > bindings is more likely to need schema information than an application using the > bindings. I see schema data as more describing the structure and semantics of the information, and the bindings describing the behaviour in the context of particular application tasks. Data + Behaviour = Objects, as they say. > > [David Brownell]: > > >That sketch omits two important features: (a) importing bindngs > > >defined for other namespaces, (b) document-specific bindings, such > > >as for the "default" namespace or embedded in a document. > > I suspect the import problems could be solved by the general XSchema scheme of > using XLink to import stuff from other files. Document-specific bindings could > be handled by associating the appropriate XSchema file with the document through > an XSchema PI. (I might be missing exactly what is meant by document-specific > bindings here.) The main issue I see with XLink there is that it's not done ... :-) There were actually two radically different issues I lumped under that moniker "document-specific bindings": (B1) stuff associated with the "default" namespace (no URI), presumably different for each document ... <binding .../> elements not associated with a namespace URI; (B2) documents which embed their own bindings, eliminating the problem of managing separate documents for bindings. The problem of referring to a set of bindings that was already defined is straightforward -- as I noted, a <?bindings uri="..."?> directive works. An XSchema PI is the same notion. - Dave 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