XML-standards-body-only-need-apply, I thought I'd make a 2 cent point.
SOMEWHERE in xmlland there is an effort to use XML tags syntax instead of DTD,
and I just have to workaround with my own for now. Maybe that is getting completed.
In any case, what I feel is that its EASIER for me to setup an XML validation thang than what I see
as a separate syntax in the DTD world. PLUS it gets awfully difficult from
an application approach to get really detailed rules e.g. arbitrary extensions to DTD
for those cases where "if its tuesday and you are in belgium, you can speak three languages unless
you are in a lambic beer brewery". To me, XML (or maybe xml) is helpful 'cause its
readable e.g. intuitive - DTD's aint' folks and never will be..
So rather than worry about it, I create an application level XML tag and then place entries for each attribute for
my own application. I am not trying to pursue STANDARDS. I am interested in STANDARDS when
the parser folks can improve their interaction with my applications. A while ago I brought up
EVENT handling which I feel is essential to getting more power from the parser but that
met a big THUNK with the people on this group at that time.
So, for my apps, after the XML parser has validated the entries via DTD, I can use a more granular
application level XML approach.
For example, to validate the XML <Command> entry <CO> and its several attributes, I have this
'validate' method hanging around for my application. At some point I could go back and build the DTD from this
information and let the parser do the error checking, but this was faster for me to build into my application
for right now than trying to grok the DTD stuff. And I don't see how the parser is going to
handle the issues right now that more errors/rules brings to the table.
<COMMAND TYPE="CO" NAME="entities" METHOD="validate">
<CO TYPE="TYPE" VALIDATE="prelim|cli|request|command|files|backup|restore|image|internal|include|internal_file|metadata|var|var_internal|var_calc|var_list|subcommand|cond_subcommand|program|cond_program|suffix|executable|log|logfile|catalog|exit|errorcode" CO="*"/>
<CO TYPE="DEFAULT" VALIDATE="*" CO="*"/>
<CO TYPE="NAME" VALIDATE="*" CO="*"/>
<CO TYPE="LOG" VALIDATE="*" CO="*"/>
<CO TYPE="PURPOSE" VALIDATE="*" CO="*"/>
<CO TYPE="CALC" VALIDATE="*" CO="var_calc"/>
<CO TYPE="COMMAND" VALIDATE="request|command|files|backup|restore|image|internal|include|internal_file|var|var_internal|metadata|var_calc|var_list|subcommand|cond_subcommand|log|logfile|catalog|exit" CO="subcommand|cond_subcommand"/>
<CO TYPE="PROGRAM" VALIDATE="*" CO="program|cond_program|subcommand|var_list"/>
<CO TYPE="METHOD" VALIDATE="subcommand|cli|map" CO="subcommand|cond_subcommand|error"/>
<CO TYPE="WHEN" VALIDATE="pre|post|during|notify|hold" CO="*"/>
<CO TYPE="CLEANUP" VALIDATE="ok|no" CO="*"/>
<CO TYPE="NOTIFY" VALIDATE="ok|no" CO="*"/>
<CO TYPE="PREFACE" VALIDATE="*" CO="cli"/>
<CO TYPE="VAR" VALIDATE="*" CO="cond_program|cond_subcommand|subcommand"/>
<CO TYPE="VAR_NAME" VALIDATE="*" CO="cond_program|cond_subcommand"/>
<CO TYPE="VAR_COMPARE" VALIDATE="==|!=|>|>>|<|<<|<=|>=" CO="cond_program|cond_subcommand"/>
<CO TYPE="MODE" VALIDATE="for_each_sub|optional|required|default" CO="cli|program|cond_program|subcommand|cond_subcommand|var|var_calc"/>
I am using Python and the code to validate this was very short and easy to implement. Maybe 50 lines.
I would see more benefit in using the parser if there was clearer interactions between the parser and the real world
application. Most parsers take a document centric approach while I am working more data driven where I use
bits of XML all through the processing of the application. So I want to be able to control just
when this level of validation is done for example. BTW, can you find the INVALID
XML on this page based on this syntax?
I suspect other folks are doing something similar here to get things going: IMHO,
this approach is more readable as well as more flexible than the DTD. Can someone
point me to the status of using XML for this kind of validation is done?
Again, if the PARSER's said they could do something more with the DTD than just
complain when an error occurred, it would be more helpful to me. I know
that the nascent XML editors need the DTDs so in the long term I'll have
to go back and support that.
F. Bryan Cooper
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format