[
Lists Home |
Date Index |
Thread Index
]
> From: Jeff Greif [mailto:jgreif@alumni.princeton.edu]
<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.
|
