[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Is Schematron (using XPath 2.0) functionally a superset of
--- Rick Jelliffe <rjelliffe@a...> ha scritto: > On Sat, 2007-11-10 at 11:58 +0100, Michele Vivoda > wrote: > > Hi, > > > > I use the schema also for its data-description > > features: to know which element/attrs are allowed, > > datatype etc, before validation, > > to _produce_ instances, that then I will validate. > > > I think that it would be hard to > > get the same description from a list of xpaths, > > or at least I wouldn't know where to start. > > Where to start? Well, forget grammars and learn > XPaths! Wow, thanks for the long response. Just as a personal background introduction, I do like XPath and XSLT which I have been using for long time. I am not a fan of w3c xml schema, but lately I am starting to surrend, dropping my "futile resistance". I haven't learned XPath2 yet. My doubts in the assertions approach are probably due also to my object-databinding background, as opposed to a documental one. > > More seriously, apart from the issue of expressive > power (which > Schematron w XSLT2 wins AFAICS) I would never > dispute that some things > are easier to express in Schematron and some things > are easier to > express in XSD; indeed, some things are easier to > express using XPaths > and some things are easier to express using > grammars. However, you set > yourself a hard task if you are defending XSD > because of its > user-friendliness :-) For sure, it is a provocation ;-) Anyway my concerns are not so much in the "express" side but in the "understand what is expressed" side. > > Why is it particularly harder to write a flat set of > declarations > > <xsh:pattern> > <sch:rule context="AAA"> > ... > </sch:rule> > > <sch:rule context="AAA/BBB"> > ... > </sch:rule> > </sch:pattern> > > > than a nested set? > > <xsd:element name="AAA"> > <xsd:complexType> > <xsd:sequence> > <xsd:element name="BBB"> > ... > </xsd:element> > ... > </xsd:sequence> > </xsd:complexType> > </xsd:element> I think that there isn't any major difference when you "write", while what is much harder for an application is understanding what is written, because "AAA/BBB" is not xml, so I cannot run an xpath or xslt on it...but ok, interpretation can be probably done, in this case, because the expression is simple. --(skip) Almost surely one cannot do anything decent with the xml of xsd either, because you need to resolve references, inheritance etc thus you would need a format where the actual schema components are described, not only (one of) their syntax; I think they were talking about this issue in some of this list yesterdays' messages. I think anyway that once you have the xml of these 'resolved xsd components', it is easier to use that instead of parsing and interpreting the XPath rules and their relationships. -- I don't know if sch:rule/@context is restricted to be a simple xpath or if it can be any xpath expression, in any case also with something simple like (in case it is allowed in shematron): AAA[not(CCC)]/BBB writing is ok, verifying is ok, but interpreting the correlation between validation and structure is imo the issue: it would involve interpreting rules possibly written in many different ways. Once you give power to the user, he will use it! It is true anyway that probably it is not possible to validate nor express such constraint with xml schema, thus it is evident that schematron is more powerful at least for validation. With w3c schema it is also possible to write the same thing in different ways but the cases are much more limited (too many there as well, in my opinion..). I understand that using simple xpaths you could check if an element is required or not (I use the schema for creation of user interfaces, and also for binding) but I have the feeling that potentially this parsing operation can get very complex. I have also the feeling that a grammar gives some extra informations apart the true/false and these infos can be used by an application for example while a user composes an instance, while the assertion must be executed hoping that somebody associated to it a meaningful message. I am thinking also about a question made some weeks ago and its solutions [1]. Don't consider me a grammar fan, they are even too complicate and too powerful! It is just that I think that they are more understandable by a tool/application. But regarding the example of [1] I think both assertions and grammars fail (even if they are the only solution available) in expressing-in-an-understandable-way the use case: the required structure (a sort of "choice-set") should be part of the type system in order to provide an easier way to understand and support it in code (I know not all cases can be covered, but this is a recurring one). -- Your posting is very accurate but unfortunately I don't have the technical knowledge to understand all what you are writing. I like the idea of extension also if I didn't get it fully. I have some questions, may be they are inappropriate, but this is what I thought. Do not take them too seriously and please don't take this post as an attack to your technology, I sincerely admire your independent effort. 1) I found the simple type example interesting; I am wondering if it is allowed to write an additional, contrasting, illogic, rule like: ---(before was less than 4, now I add more than 6)-- <sch:rule abstract="true" id="t3" role="xsd-simpleType" > <sch:rule extends="t2" /> <sch:assert test=". > 6" role="xsd-facet-maxExclusive"> The value should be more than 6 </sch:assert> </sh:rule> -- 2) I am not sure about the one below because I don't understand the syntax of the complex content example, but I see some dtd-syntax (don't know if it is actually used..). >( BBB, CCC+, DDD | EEE, FFF? ') If this is used by schematron, letting apart the issue I mentioned before (parsing, interpreting, not xml), isn't using DTD grammar a step backward ? 3) I suppose schematron can express the semantics of complex types derivation (extension I think is the issue here, restriction is just adding rules ?). Is it possible to roundtrip complex types derivation? 4) How do you deal with (ignorable) wildcards ? I suppose they are quite hard to insert in xpaths..if I have to deal with such constructs in xslt I usually do a first pass removing wildcard nodes and then do an other pass as they never existed. Otherwise expressions get very complicate, in my opinion. 5) About types. If I know an <Employee> instance is valid, is there any possibility to know that <Employee> is a <Person> + @EmployeeID ? 6) My last doubt is about the relations between XPath2 and W3C Schema: XPath2 depends on W3C Schema, so isnt' that using xpath2 actually means using also somehow w3c schema ? Have you been assimilated ? ;-) Cheers Michele Vivoda [1] http://lists.xml.org/archives/xml-dev/200711/msg00016.html ___________________________________ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|