Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML spec and XSD
 Phillipe, That sounds pretty slick--definitely sounds like it goes even above and beyond what I've been looking for in many ways. I noticed though that you didn't comment on my complaints about typing--does ASL support the concept of complex data typing with type derivation, etc.? If so, it definitely sounds promising. By the way, I love your signature--gave me a great laugh this morning! :-) Doug Glidden Software Engineer The Boeing Company Douglass.A.Glidden@boeing.com -----Original Message----- From: Philippe Poulard [mailto:philippe.poulard@sophia.inria.fr] Sent: Thursday, November 19, 2009 05:42 To: Glidden, Douglass A Cc: xml-dev@lists.xml.org Subject: Re: XML spec and XSD Hi, I have presented the "Active Schema Language" at Balisage last year, that covers rather well most of the features you expect: http://www.balisage.net/Proceedings/vol1/html/Poulard01/BalisageVol1-Poulard01.html Slides: http://hal.inria.fr/docs/00/32/26/61/ANNEX/Bal2008poul061003.pdf Implementation: http://reflex.gforge.inria.fr/ Glidden, Douglass A wrote: > From the perspective of an application developer who uses XML for storing fairly complex hierarchical data (as opposed to documents), I have a very basic question: Is there any real, practical reason that Relax NG is _universally_ better than XSD? > > Here's the background for my question: I've been using XSDs for generating object-oriented data models for some time, and have been frustrated by various inflexibilities in XSDs. For instance: > - Derivation by restriction, while conceptually very useful, seems slightly cumbersome in operation; in particular, I wish it could be accomplished with less repetition (I'm a fanatical believer in DRY). I can live with the repetition, though, because I am assured that, if I make a typographical or some other error, the XSD will (almost) always fail to validate ("Bar is not a valid restriction of Foo"), so the the possiblity of unintended changes being introduced due to the repetition is kept to a minimum. > - Certain fairly simple data structures can only be achieved in XSD (if at all) with ridiculously verbose patterns; for instance, how do you represent a structure with five possible elements, at least one of which must be present and none of which may be repeated? The best method I have found takes about 25 lines and far too much code repetition. With ASL, you just express things in the way you think of them: <asl:element name="property"> <asl:select max-occurs="unbounded"> <asl:element ref-elem="width" min-occurs="0"/> <asl:element ref-elem="color" min-occurs="0"/> <asl:element ref-elem="border" min-occurs="0"/> </asl:select> </asl:element> by default, cardinalities are set to 1, which means that <property> must have at least 1 occurrence, and within, the other elements can't appear more than once <property><!--valid--> <width/> </property> <property><!--valid--> <width/> <border/> </property> <property> <width/> <width/><!--unexpected element--> </property> <property> <width/> <border/> <width/><!--unexpected element--> </property> <property/><!--element missing--> > - Most business logic cannot be represented, like "the value of the foo element must be less than or equal to the value of the bar element". You will find here some usefull use cases of business logic representation: http://reflex.gforge.inria.fr/tutorial-schemas.html > - I occasionally was foiled by XSDs strict "no ambiguity" rules, which make it difficult to enforce rules such as "if the value of the foo element is xyz, then the bar and baz elements are required, but otherwise they are optional". Straightforward in ASL: <asl:element name="xxxxxx"> <xcl:if test="{/path/to/foo = 'xyz'}"> <xcl:then> <asl:sequence> <asl:element ref-elem="bar"/> <asl:element ref-elem="baz"/> </asl:sequence> </xcl:then> <xcl:else> <asl:sequence> <asl:element ref-elem="bar" min-occurs="0"/> <asl:element ref-elem="baz" min-occurs="0"/> </asl:sequence> </xcl:else> </xcl:if> </asl:element> you will notice that ASL can be mixed with other XML libraries (above, XCL that stands for the XML Control Language); this is a very useful feature that makes the abstract tree of the schema dynamic (other schema technologies have a static abstract tree) which boost the expressiveness of the language (isn't that a features that you are looking for ?) > > Nonetheless, I have been more or less pleased with the final results in most cases. Having heard much praise of Relax NG, I recently decided to try it out, hoping it would be able to resolve these issues. Here's what I found: > - It does relieve the "no ambiguity" problem and makes enforcing that sort of rules much easier. > - It does not resolve most of the business logic issues, but there are other technologies that can be used in combination with either Relax NG or XSD to resolve these issues, so that can be worked around in either case. > - It does not appear to relieve the complexity of representing some types of data structures (see the one described above-as far as I can tell, it would not be significantly easier to define in Relax NG than it is in XSD). > - There is only a rudimentary concept of type definition and virually > none of inheritance. Designing good, object-oriented data models is > practically impossible in Relax NG; for me, this is a HUGE deficiency. > For instance, say Foo is an abstract data type with several fields, > including an id field (any mixed data allowed) and a type field (with > enumerated values); Bar is one of several concrete subtypes of Foo, > which restricts the content of the id field (must contain two > elements, a groupId and a subId) and the type field (to a subset of > the values enumerated by Foo) and appends several new fields; other > subtypes have completely different restrictions on the id and type > fields and append various different new fields. In XSD, implementing > this is fairly straightforward (although not necessarily simple and > certainly more verbose than I would prefer): Foo is an abstract > complex type, and Bar and the other subtypes must derive from it first > via restriction (creating the re strictions on id and type) and then via extension (appending the new fields). In Relax NG, by contrast, I could find only two ways of doing this, neither of which was at all acceptable: One is to get rid of Foo completely and reference its fields separately in each subtype-this is unacceptable to me as it completely violates DRY and object-oriented design; the other is to define each subtype of Foo in a separate file, importing Foo and redefining as necessary-this is marginally better from an OOP point-of-view, but still makes it impossible for a schema to use "any valid subtype of Foo" as a content definition without violating the Open-Closed principle. > - Relax NG provides no way of specifying cardinalities other than 0, 1, and infinity! This is also a big one for me--if I need at least 2 and no more than 20 occurrences of the foo element (fairly common in my data definitions), there's NO WAY I'm going to define two required foo elements and eighteen optional ones! In ASL, cardinalities support "2" or "20", but can also be dynamic "{1+1}" or "{count(../column[1]/cell)}" or whatever you find useful with XPath > > Now, I'm hoping that some Relax NG expert will come along and prove me wrong about some or all of these things, since I only experimented with it for a couple of days. If not, for me these deficiencies in Relax NG *far* outweigh its benefits over XSD-there's really no comparison. As much as I would like to see some aspects of XSD improved, unless someone can propose real alternatives for issues like the ones above, Relax NG is simply not an option for the type of data I work with. > > As a postscript, let me say I'm very thankful that the tone of this > thread has been gradually transitioning to actual constructive > argument (at which this list is normally rather good) rather than the > ridiculously juvenile mud-slinging that was predominant early last > week-in particular, I've appreciated the level-headed input from Jim > Tivy, Liam Quin, Ken Holman, and Michael Kay. Unfortunately there are > still some emotionally charged but pretty much meaningless (or worse, > completely false) words being thrown around, but at least those aren't > in the majority anymore. In all good humor, I have to say that > XML-dev is by far the most argumentative mailing list to which I've > ever been a subscriber. :-) > > Doug Glidden > Software Engineer > The Boeing Company > Douglass.A.Glidden@boeing.com > ______________________________________________________________________ > _ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS to > support XML implementation and development. To minimize spam in the > archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org List archive: > http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > -- Cordialement, /// (. .) --------ooO--(_)--Ooo-------- | Philippe Poulard | ----------------------------- http://reflex.gforge.inria.fr/ Have the RefleX ! 
[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
|
|||||||||
