[
Lists Home |
Date Index |
Thread Index
]
Hi Len,
Bullard, Claude L (Len) wrote:
>That seems like a handy utility to have. I've often wondered
>if many of the issues that popup here particularly with regard
>to augmentation of Schema information could not better be handled
>in XSLT. Sometimes I think we don't need more tools; we need to be
>more inventive with the tools we have.
>
>
Good, it's at http://www.schemavalid.com/utils/iExmlProjectFilter.zip -
it's simpler if more brutal than using extension / restriction /
redefines (which its target users were not comfortable with) and
delivers pleasantly legible pan- and per-project documents.
>An interesting best practice thread might be
>
>1. What CAN'T be handled with an authoritative transform?
>
"authoritative" meaning "as specified by the original (or agreed) schema
author"?
>2. Given transforms, how much post-parse information really
> needs a more powerful schema formalism? If so, when?
>
I'm sorry, I don't really understand how transforms effect the PSVI
requirement - can you elaborate?
>3. What requirements for a schema language should be posed for
> any project and what should be explicit to a project? It
> seems to me that we don't have many criteria for evaluating
> these proposed mods and features for schema languages?
>
Some of these requirements may emerge during projects, I agree it would
be nice to list them for future use and better understanding.
>I don't find it compelling to have a means to validate or
>augment that can't be inspected and proven by readily
>available means if it has to cited normatively. That's
>the transparency requirement. But it also may just be my
>SGML Ludditism showing because I accept a lot of behind
>the scenes manipulation from my relational toolsets.
>
I think the effect of this utility works is obvious enough to count as
totally transparent. On the other hand more powerful tools might use the
same underlying technology and have equally open source, but eventually
the complexity of effect will take one to the other side of the
indeterminate "transparency v. opacity" boundary.
>Flatten out one piece of the complexity carpet and darned
>if another part doesn't ripple. Try to rehost an MS Access
>app into Visual Foxpro and watch code disappear into
>the more powerful but explicitly relational language
>features of Fox. What goes on beneath the rug? We aren't
>supposed to care if the results are provably the same.
>
>Shouldn't that be the case for the schema language processors?
>
Yes, let's hope layering leads to a more complementary outcome.
Francis.
--
"Never mind manoeuvre, go straight at 'em." - Admiral Horatio Nelson
|
