Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Are we losing out because of grammars?
 "K.Kawaguchi" wrote: > And I read your tutorial that states > > > The role of TREX is ... not to assist in interpretation of the > > documents belonging to the class > > (1) I think "assistance of the interpretation" is important requirement > of schema language (or at least I think there are solid needs). > But it seems to me that you don't share this view, do you. Why? I think that + validation, and + "assistance of interpretation" or, more generally, augmenting the infoset are separate functions and that mushing the two together is a bad idea: I may want to validate without augmenting the infoset and I may want to augment the infoset without validating. In SGML, validation was not cleanly separated from parsing. I think this was a significant problem with SGML: you couldn't do anything do an SGML document without running it through a complex, validating parser. XML changed this with the introduction of the concept of well-formedness, which separated out validation from parsing. It didn't in my view go quite far enough in this separation: certain tasks were lumped in with validation that were logically separable. For example, validating parsers are required to handle default attributes declared in the external DTD, whereas non-validating parsers are not. This has caused nothing but trouble. Users naturally want to get the same results whether they are validating or not, which means they need non-validating parsers do all the things required of validating parsers that affect the infoset. The lesson I draw from this is that it's better to keep these things as well separated as possible. > (2) If we set aside ambiguity issue, it is easy to add "assistance" > capability to TREX, by (for example) introducing "type" attribute to > each <element> and <attribute> element in the pattern. > Do you have any reason to discourage this? No reason. I see no problem with annotating TREX patterns with additional information, and having separate processes leverage that information to do things other than validation. So long as things are kept cleanly separated, this sort of reuse seems a good thing to me. Processes that reuse TREX patterns for purposes other than validation may choose not to allow all TREX patterns: for example, they might exclude certain operators (such as concur) or they might impose certain additional constraints relating to ambiguity. TREX has all the support for this that I think it needs: it allows you to add new attributes and child elements to TREX elements in the pattern, so long as they are in a separate namespace. James 
|
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
|
|||||||||
