On 04/23/2013 09:49 PM, Timothy W. Cook wrote: > > Hi Bert, > > On Tue, Apr 23, 2013 at 3:00 PM, Bert Verhees <bert.verhees at rosa.nl > <mailto:bert.verhees at rosa.nl>> wrote: > > I said already, study it, don't following your intuition. I > already gave you a simple example how RelaxNG could have prevented > your GUID-element-names, a few weeks ago. > Anyway, I will come back to this, in the mean time, take a look at > the mail archive, you should find the example there. > > Ah, I found it > >> >/ RelaxNG allows complex elements with different types in the same >> group >> />/ with the same name and checks at run/validation time how to validate >> />/ an element. >> />/ >> />/ Suppose you want this: >> />/ >> />/ <addressBook> >> />/ <card> >> />/ <givenName>John</givenName> >> />/ <familyName>Smith</familyName> >> />/ <email>js at example.com >> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org></email> >> />/ </card> >> />/ <card> >> />/ <name>Fred Bloggs</name> >> />/ <email>fb at example.net >> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org></email> >> />/ <note>bla bla bla</note> >> />/ </card> >> />/ </addressBook> >> />/ >> />/ Two kind of complextype of "card", one containing name, email and >> the >> />/ other containing firstName, familyName, email. >> />/ In XML-schema this is not possible. >> />/ >> />/ In RelaxNG the schema looks like this: >> />/ >> />/ element addressBook { >> />/ element card { >> />/ (element name { text } >> />/ | (element givenName { text }, >> />/ element familyName { text })), >> />/ element email { text }, >> />/ element note { text }? >> />/ }* >> />/ } >> />/ >> />/ It has a card-definition with two elements for both: email and note, >> />/ the element note is optional. >> />/ And it validates the first group as: it must be a name OR it must be >> />/ firstName and lastName./ >> // > > So, it is able to validate two elements with the same name, but a > different content/datatype. This is just what is needed to handle > the ADL constructs which have the similar characteristics. > > I think that you will find that this is not the same requirement that > you are going to face when you create constraint models against a > reference model. At least I cannot see where your analogy holds up. > > What you are using for an example is a one level model of a document > with optional elements as simple types. What you have been > describing though (I assume) is the use of RelaxNGs 'combine' > attribute (set to choice or interleave). But in your example I do not > see that you are using 'define' to create your complexType definition > so I cannot comment further on this.
The "define" is in the second part of the example, that is (called) the compact notation although there is also another notation for Relax NG which is more easier to understand for people used to XML-Schema. The other notation is like ..... (partially) <element name="addressBook"> <element name="card"> <choice> <group> etc ...... </group> <group> etc ...... </group> </choice> </element> </element> I can recommend the book of Eric van der Vlist, it is also free for download or read online http://books.xmlschemata.org/relaxng/ > > I am interested in your results and how your paths end up being > negotiated if you develop complex types with multiple possible element > names as leaf nodes. Just as in the example? This is one of the advantages of RelaxNG. You wonder why RelaxNG still exists, 10 years after the definition of XML-Schema 1.1? Here you have an answer. Bert -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130423/56b263db/attachment-0001.html>
