RE: [xml-dev] When to Validate XML?

[Jeff Lowery <jlowery@scenicsoft.com>]

> This is more like passing an Object and let each app coerce 
> to its local 
> type, and succeed if such coercion is possible (as per 
> generalization).
> 
> However, what if one of the apps want to be more precise, and 
> not want 
> to rely on wildcards? Can it not map the schema URI to a 
> locally defined 
>   (and more precise) schema?

Yes, as long as that schema uses derived types (or element substitution, but
that's a one-way proposition). The point is that type derivation gives you
some ability to customizing the schema for the local app. If data is to flow
bidirectionally, then the originating source has to react passively to
extended type information (restricted types are not an issue for the
originating source). So the original schema has control of the valuespaces
*for data items it knows about* and preserves and regurgitates additional
information for extended type instances it doesn't know about. If approach
is somehow unreasonable for the originating source, then it can finalize its
definitions, which prevents type derivations.

> 
> By this, I'm not advocating a magic and unknown world where 
> no App has 
> as idea of what's flowing through. I'm just debating the 
> possibility of 
> such "local" decisions. The same applies to constraints too.

I think we're in basic agreement, I'm just trying to clear up any
misunderstanding.

> An app may choose to validate what it is interested in and not worry 
> about the rest, still adhearing to a common schema. This is 
> fine, expect 
> when I consider change propagation. When the common schema 
> changes, each 
> app will have to update its schemas (can be painful, sometimes) even 
> though it may not really depend on the changes. 

There was a thread, either here or on xmlschema-dev, that talked about
versioning of XML Schemas. Actually, Patricia Walmsley wrote it up on
Costello's Best Practices website:

http://www.xfront.com/BestPracticesHomepage.html

If you're app can access version information, it should be able to make
intelligent choices about how it wants to handle new versions (reject,
process laxly, full validation). If one is really clever (not me!), one
could encode diff information (using XSLT?) in the data model itself, which
an app could use to translate new version data into an into the old version
format. 

Derived schema documents are not always going to be valid with new versions
of the base schema, though. Hmmmm....


> If I add data binding 
> (from this list, I see that data binding is gaining 
> popularity) to this, 
> I see more troubles. Now, with each change, each app will 
> have to update 
> its data binding classes (that is compile, build, test, stage, and 
> deploy) for each change. (Makes me wonder where the "X" in 
> the XML has 
> gone).

There's not computing problem that can't be solved by adding another layer
of indirection :-)

Really, though, this is not a new problem. First of all, binding code
generated from schemas is going to be low-level. Your app developers will
want classes that offer higher-level conceptual models of the data. So, if
you divorce the application from the generated code by a layer in between,
you localize the code that needs to be changed when new binding code is
generated.

Granted, that works for minor data model tweaks and extensions, not for
wholesale modifications of the metadata structure. You really have no
recourse than to rewrite your application in that case; but if you build
your house on a shaky foundation, well...

> 
> I don't know if these issues are realistic, and I'm looking for 
> experiences from other people in this group.

So am I! Let's see what happens...