Re: RE: [Summary] Should Subject Matter Experts DetermineXML D
Costello, Roger L. wrote: > Suppose I interview several Book SMEs. They tell me that a Book is > comprised of a Title, Author, Date, ISBN, and Publisher. > > I document this data and the relationship (parent-child relationship > between Book and Title, Author, Date, ISBN, Publisher) in a Book Data > Specification. For what purpose does this specification exist? If it's intended to be a model for the SMEs to enter Book Data, it's a bad idea because there are too many weak spots. It would be easy to put a typo in the ISBN, so a clever Implementation Expert (?) might suggest that the SME enters the ISBN and the system generates the rest of the data by querying some external source. So maybe it's the specification for the SMEs to view Book Data? It's still a bad idea. Is this the only view of this data? What if it's also going to be subsetted for particular publishers, so will have the Publisher data removed? What if that's all that the SMEs need to approve, but accessibility guidelines dictate that the data be augmented in some way for delivery? > The Book Data Specification is handed off to a techie who then > creates an XML Schema implementation and several sample XML > instances. > > There may be several iterations to get any confusion cleared up. > > I end up with an XML Schema that is independent of any specific > application. Thus, it supports the unanticipated user. No, you end up with a schema that burdens all of the players with the crap of the others. Schemas are a poor mechanism for documenting requirements - they can be okay if there's a one-to-one mapping and the data looks the same all the way through the system, but otherwise they're pretty lame. You might consider defining a schema for the SMEs interface and another for each of the various uses of the data and then tie them together with requirements, but the schema mechanism itself isn't adding a whole lot of value to the definition of the system. The crucial factor is the information flow through the system, not whether a point-in-time validation will succeed. > I don't see data flows, application architecture diagrams, or business > processes entering into the picture at all. > > It seems to be simply a matter of identifying the data cow path, > documenting it, and implementing it with an XML Schema. You *can't* see data flows etc. entering the picture, because they break the schema. Either that, or you allow everything and try to somehow impose the semantics that you intended at a particular point, since you didn't formalize them in the schema. > What and how applications use the resulting XML instances is outside > the scope of the Data Specification - XML Schema Implementation > activity. > > No? It's outside the scope if you just want to create data and validate it. It's not if the intention is to deliver a system whereby a user enters the Book information into an application designed to minimize errors and repurpose the data to accommodate an as yet undefined set of outputs. Validation is so nineties... :-) Marcus Carr
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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