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

RE: Best Practice - beyond schema

• To: 'Francis Norton' <francis@r...>
• Subject: RE: Best Practice - beyond schema
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Mon, 17 Jun 2002 13:03:54 -0500
• Cc: Xml-Dev <xml-dev@l...>

Hi Francis:

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.

An interesting best practice thread might be

1. What CAN'T be handled with an authoritative transform?

2. Given transforms, how much post-parse information really 
   needs a more powerful schema formalism?  If so, when? 

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?

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. 

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?

len


From: Francis Norton [mailto:francis@r...]

Hi Len,

Bullard, Claude L (Len) wrote:

>An alternative is to move the local definition to a transformation 
>document, eg, XSLT over the XML Schema.   The technical 
>advantage here is to have the modifications in a single 
>automated document including any value constraint controls 
>which presumably will be local  The XML Schema is one and the authority 
>is centralized.  The XSLT modifier is one and is owned by the 
>local authority.  
>
I have written a utility to include or exclude xsd elements for / from a specific project, using embedded appinfo markup and an XSLT transform that takes the project name as a commandline parameter.

I'll pop it up on a site if anyone thinks it might be interesting

• Follow-Ups:
  • Re: Best Practice - beyond schema
    • From: Francis Norton <francis@r...>

• Prev by Date: Re: DSDL part 9: new namespace declarations not needed as part of DTD syntax?
• Next by Date: Re: DSDL part 9: new namespace declarations not needed as part of DTD syntax?
• Previous by thread: RE: Best Practice - beyond schema
• Next by thread: Re: Best Practice - beyond schema
• Index(es):
  • Date
  • Thread