[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: RELAX NG Marketing (was RE: Do Names Matt er?)
> From: Jeff Greif [mailto:jgreif@a...] <snip/> > In > many cases, the producer of the configuration instance > document does not > know enough about the meaning of a given setting to be > expected to insert > the setting as a required item. Hand editing of a configuration file by a user who doesn't understand enough about the meaning of setting to be expected to insert a correct value? This strikes me as a highly suspect use case. Certainly, though, there are valid use cases for some applications' need to augment a document's infoset. But why do certain augmentations (e.g. attribute and element defaulting) deserve special status, and why must they be conflated with the task of validation? There are plenty of strategies the application could employ to do infoset augmentation that do not require that core XML standards conflate the roles of validation and value defaulting in such a manner that every consumer of XML documents *must* assume that it *may* not be able to reliably interpret the content of a document without validating it, and cannot assume that the mere task of validation may alter the infoset. <snip/> > 2. The vendor can send out a new DTD or schema changing > default values for > features that were not approved for certain classes of usage > (for instance, > certain high-security usage) when the software was released, > but since had > been certified or otherwise vetted. This could also be a very bad thing. An historical document suddenly has its infoset altered by a change to a DTD or schema. I think it would be more commonly the case that you would *not* want such a side effect. Indeed, this sounds like it would be bad practice in the general case. On the other hand, there are certainly use cases where you might want to do such a thing. There are also use cases for wanting to do more extensive augmentation, or even transform a document into an entirely different format. There are certainly ways of accomplishing such tasks without relying upon validation as the vehicle for accomplishing them. > 3. When the default values are the ones that are right or > reasonable for > normal operation, the people configuring the application can > avoid having to > know about them, while they are still configurable without > having to touch > the application code and can be inspected in the schema or DTD. I'd have no problem with the whole notion of default attribute and element values if it were not for the fact that current XML standards *force* consumers to have to contend with them except in those cases where an application knows a priori that this will not be an issue with those documents it will consume. This is backwards. A consumer should be able to rely upon the fact that the infoset of a document will not change just by virtue of whether or not validation is enabled. I'd like to hear use cases for why certain lightweight transformations such as attribute or element defaulting deserve a special status in XML standards and must be conflated with the task of validation, as opposed to being explicitly controlled by the application.
|
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
|