[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Too many moving parts: Re: meta-specs
Len, > I am curious about various approaches that tie it all together > and in this particular case, wondering if for some time period > it may be wise to focus on the instances and therefore, XML > Schemas as a simple means to get definitions for instances. > In total there would be many modules, but to begin with, having > chosen some categories of information, we sort out membership > of various documents and record that sorting in the document > type (schema). It takes a "feel" for the data domains followed > by normalization, then iterate until it *feels right*. > > Is that too... Extreme? :-) The question is how to best capture this schema as a collection. Whatever works. You might write a Schematron and keep adding assertions until all the instances you want in are in and all the instances you want out are out. > > I understand that you are looking at a type system > independent of the schema language. I need to understand > that better. My dilemma is "too many moving parts", that > is, having so many ways to design that it becomes difficult > to choose. Schemas I know so I tend toward what I know and > that isn't always the best metric. Sure. What I would like to ultimately see is for people to use whatever tools or languages feel best for their task. We get back into the software project composed of multiple modules in multiple languages trying to work together. So objects were invented as a way to abstract a module based on its properties and methods. In the same way that a bunch of code becomes a "method" and a data structure becomes a "property", a schema module or a constraint or an XPath becomes a type (each defines a set of instances). Types as sets of nodes abstracts the concept of "type" from the particular language used to express the constraints on the set. Perhaps we will ultimately be able to validate a document which contains several vocabularies in different namespaces and each vocabulary is described using a different language. This meta-schema validator just asks each node: are you ok? and the node is responsible for figuring out if it and what it contains is ok. If everything is ok the document is valid. The problem with too many moving parts, is not that there are too many parts, or that they are moving, but that they are moving in different directions without regard for eachother. With a few screws and some oil perhaps we can assemble a bunch of spinning cogwheels into a swiss watch. > > I like your approach in that it appeals to my need to start > as much as possible from simple devices. If we have the > instances nailed down, we have a pretty good idea how to > then begin to look at different schemata techniques and > thus, which one best models some particular kinds of > constraints because we know what the outputs look like. > If we got the categories right, we are in the right > neighborhood. So I am following this with great interest. > > I realize how unscientific it all sounds, but after > some years of doing this, I am convinced schema design > is art supported by method. :-) It _is_ scientific :-) The "Schema Algebra" is just a fancy formal way of stating the same. The only reason this needs to be said in a mathematical way is that we need to be very precise about what we are doing. Precision can be simple. -Jonathan
|
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
|