[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Best Practice - beyond schema

• To: "Bullard, Claude L (Len)" <clbullar@i...>
• Subject: Re: Best Practice - beyond schema
• From: Francis Norton <francis@r...>
• Date: Tue, 18 Jun 2002 11:36:37 +0100
• Cc: Xml-Dev <xml-dev@l...>
• References: <2C61CCE8A870D211A523080009B94E430752B588@HQ5>
• User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530

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

• References:
  • RE: Best Practice - beyond schema
    • From: "Bullard, Claude L (Len)" <clbullar@i...>

• Prev by Date: Re: Best Practice - beyond schema
• Next by Date: Re: Best Practice - beyond schema
• Previous by thread: RE: Best Practice - beyond schema
• Next by thread: RE: Best Practice - beyond schema
• Index(es):
  • Date
  • Thread