Trying to understand the openEHR Information Model
Verstuurd vanaf mijn iPad Op 22 apr. 2013 om 23:19 heeft Thomas Beale thomas.beale at oceaninformatics.com het volgende geschreven: which rules is it breaking? As far as I know, openEHR XML documents validate normally against the schemas. yes, I said it wrong, later in the message I said it better and I forgot to remove this statement. So let me correct myself: You cannot represent all Archetype constraints in XML schema, you can of course validate against the master scheme, but that is not very interesting. To validate you need to validate against the constraints. That is the important point of multi level modeling. I discovered some important problems, besides the restriction/extension structure, which is quite disturbing. You are not allowed to restrict and extend an derived element at the same time. Just for clarity, A restriction in deriving in XML Schema is not the same as constraining in ADL. Read the Priscilla Walmsley book on this, she explains it very well. There are ways around this, but it is not very elegant. Another very important restriction for using XML Schema, in my opinion, is that you cannot have two or more elements with the same name but a different data type. This data type must be in detail the same. XML Schema regards an Element with a Dv_Text as a different datatype from an Element with a Dv_CodedText. Both elements will be called items in an XML schema representing an OpenEhr data structure, and thus is not allowed having them different details in data types. This brought Tim Cook to using the GUIDs in the element-names, which is unworkable in my opinion, and above all, probably unnecessary, because in RelaxNG this restriction does not exist. Other tricks are also possible, for example augmenting element-names during validation-time, but also that is cumbersome code, and that just for avoiding the problems of an ivory tower stupid W3C standard? So this is indeed an important restriction, which makes the clean use of XML Schema impossible in OpenEhr-rm, or any other ADL based multi level modeling system. Dirty use, tricks, ignoring validation errors, etc of course remain possible. There are more restrictions, but less important. For example it is not possible to support the Dv_Time constraint/pattern hh:??:??, same for Dv_DateTime. In the Dv_Date is also a problem, but can be worked around by the alternative rule, but on another way then it is meant to use. Anyway, after a few weeks I will probably define the OpenEhr RM and all possible constraints in RelaxNG. Bert
Trying to understand the openEHR Information Model
Verstuurd vanaf mijn iPad Op 22 apr. 2013 om 23:19 heeft Thomas Beale thomas.beale at oceaninformatics.com het volgende geschreven: well, we already had that debate. It's not what we use it for - we don't do any 'modelling' in XSD, it's just an interoperability schema. Sorry I explained it again, Maybe someone reading had missed it. :) I think we agree largely on this. Bert
Trying to understand the openEHR Information Model
On 22/04/2013 23:26, Bert Verhees wrote: Verstuurd vanaf mijn iPad Op 22 apr. 2013 om 23:19 heeft Thomas Beale thomas.beale at oceaninformatics.com het volgende geschreven: which rules is it breaking? As far as I know, openEHR XML documents validate normally against the schemas. yes, I said it wrong, later in the message I said it better and I forgot to remove this statement. So let me correct myself: You cannot represent all Archetype constraints in XML schema, you can of course validate against the master scheme, but that is not very interesting. To validate you need to validate against the constraints. That is the important point of multi level modeling. that's true if you try to use XSD in its native form. I have been saying the same thing for years. But you can represent archetypes in XML in another way - as a straight object serialisation of an AOM structure. Have a look at the XML output of the current ADL workbench. I didn't create an XSD for that, but it would certainly be possible. The XML format used by the Archetype Editor is of the latter form. I discovered some important problems, besides the restriction/extension structure, which is quite disturbing. You are not allowed to restrict and extend an derived element at the same time. Just for clarity, A restriction in deriving in XML Schema is not the same as constraining in ADL. Read the Priscilla Walmsley book on this, she explains it very well. yes, and she is correct, it's a mess. See my comments to Tim earlier ;-) But there is no danger of openEHR doing this, I think, since we know it won't work effectively. That's why all the There are ways around this, but it is not very elegant. Another very important restriction for using XML Schema, in my opinion, is that you cannot have two or more elements with the same name but a different data type. This data type must be in detail the same. XML Schema regards an Element with a Dv_Text as a different datatype from an Element with a Dv_CodedText. Both elements will be called items in an XML schema representing an OpenEhr data structure, and thus is not allowed having them different details in data types. This brought Tim Cook to using the GUIDs in the element-names, which is unworkable in my opinion, and above all, probably unnecessary, because in RelaxNG this restriction does not exist. Other tricks are also possible, for example augmenting element-names during validation-time, but also that is cumbersome code, and that just for avoiding the problems of an ivory tower stupid W3C standard? So this is indeed an important restriction, which makes the clean use of XML Schema impossible in OpenEhr-rm, or any other ADL based multi level modeling system. Dirty use, tricks, ignoring validation errors, etc of course remain possible. There are more restrictions, but less important. For example it is not possible to support the Dv_Time constraint/pattern hh:??:??, same for Dv_DateTime. In the Dv_Date is also a problem, but can be worked around by the alternative rule, but on another way then it is meant to use. Anyway, after a few weeks I will probably define the OpenEhr RM and all possible constraints in RelaxNG. I agree with most of this, but I don't understand the issue - we don't do any of the above anyway. That's why we have ADL, AOM, and object transforms of the AOM... am I missing something? - thomas
Trying to understand the openEHR Information Model
have ADL, AOM, and object transforms What is missing is that xml offers validation and query out of the box, which means it has been developed and optimized for years by many companies and communities, and mostly is good quality software. Op 23 apr. 2013 09:14 schreef Thomas Beale thomas.beale at oceaninformatics.com het volgende: On 22/04/2013 23:26, Bert Verhees wrote: Verstuurd vanaf mijn iPad Op 22 apr. 2013 om 23:19 heeft Thomas Beale thomas.beale@** oceaninformatics.com thomas.beale at oceaninformatics.com het volgende geschreven: which rules is it breaking? As far as I know, openEHR XML documents validate normally against the schemas. yes, I said it wrong, later in the message I said it better and I forgot to remove this statement. So let me correct myself: You cannot represent all Archetype constraints in XML schema, you can of course validate against the master scheme, but that is not very interesting. To validate you need to validate against the constraints. That is the important point of multi level modeling. that's true if you try to use XSD in its native form. I have been saying the same thing for years. But you can represent archetypes in XML in another way - as a straight object serialisation of an AOM structure. Have a look at the XML output of the current ADL workbench. I didn't create an XSD for that, but it would certainly be possible. The XML format used by the Archetype Editor is of the latter form. I discovered some important problems, besides the restriction/extension structure, which is quite disturbing. You are not allowed to restrict and extend an derived element at the same time. Just for clarity, A restriction in deriving in XML Schema is not the same as constraining in ADL. Read the Priscilla Walmsley book on this, she explains it very well. yes, and she is correct, it's a mess. See my comments to Tim earlier ;-) But there is no danger of openEHR doing this, I think, since we know it won't work effectively. That's why all the There are ways around this, but it is not very elegant. Another very important restriction for using XML Schema, in my opinion, is that you cannot have two or more elements with the same name but a different data type. This data type must be in detail the same. XML Schema regards an Element with a Dv_Text as a different datatype from an Element with a Dv_CodedText. Both elements will be called items in an XML schema representing an OpenEhr data structure, and thus is not allowed having them different details in data types. This brought Tim Cook to using the GUIDs in the element-names, which is unworkable in my opinion, and above all, probably unnecessary, because in RelaxNG this restriction does not exist. Other tricks are also possible, for example augmenting element-names during validation-time, but also that is cumbersome code, and that just for avoiding the problems of an ivory tower stupid W3C standard? So this is indeed an important restriction, which makes the clean use of XML Schema impossible in OpenEhr-rm, or any other ADL based multi level modeling system. Dirty use, tricks, ignoring validation errors, etc of course remain possible. There are more restrictions, but less important. For example it is not possible to support the Dv_Time constraint/pattern hh:??:??, same for Dv_DateTime. In the Dv_Date is also a problem, but can be worked around by the alternative rule, but on another way then it is meant to use. Anyway, after a few weeks I will probably define the OpenEhr RM and all possible constraints in RelaxNG. I agree with most of this, but I don't understand the issue - we don't do any of the above anyway. That's why we have ADL, AOM, and object transforms of the AOM... am I missing something? - thomas __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130423/5b96915e/attachment.html
Trying to understand the openEHR Information Model
On 23/04/2013 10:37, Bert Verhees wrote: have ADL, AOM, and object transforms What is missing is that xml offers validation and query out of the box, which means it has been developed and optimized for years by many companies and communities, and mostly is good quality software. ok but we just agreed that XSD doesn't do the kind of validation that is needed by archetypes, so I think what you are really proposing is XML based on Relax NG as a sufficiently powerful approach that would a) implement the required constraint semantics of archetypes and b) create data that can be queried by Xpath/Xquery out of the box? Is that your suggestion? If so, my reaction would be: let's investigate as a community. I don't think anyone has sufficiently investigated Relax NG or Schematron for openEHR purposes, and in hindsight we probably should have. It would be very interesting indeed to see how much better it would work than XSD. I think if you make any progress in your work on these questions, let's turn them into specs / guidelines / whatever for general use in openEHR. - thomas
Trying to understand the openEHR Information Model
Well, we have explored the use of Schematron and how it can be automatically generated from archetypes (the idea was to rewrite CDA implementation guides as CDA archetypes and generate schematron automatically from them). I won't go into much detail, but we were able to generate assert and report instructions easily. The only thing unexplored was the use of phases. I would say we are in the 80 of the 80/20 rule :) 2013/4/23 Thomas Beale thomas.beale at oceaninformatics.com: On 23/04/2013 10:37, Bert Verhees wrote: have ADL, AOM, and object transforms What is missing is that xml offers validation and query out of the box, which means it has been developed and optimized for years by many companies and communities, and mostly is good quality software. ok but we just agreed that XSD doesn't do the kind of validation that is needed by archetypes, so I think what you are really proposing is XML based on Relax NG as a sufficiently powerful approach that would a) implement the required constraint semantics of archetypes and b) create data that can be queried by Xpath/Xquery out of the box? Is that your suggestion? If so, my reaction would be: let's investigate as a community. I don't think anyone has sufficiently investigated Relax NG or Schematron for openEHR purposes, and in hindsight we probably should have. It would be very interesting indeed to see how much better it would work than XSD. I think if you make any progress in your work on these questions, let's turn them into specs / guidelines / whatever for general use in openEHR. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Trying to understand the openEHR Information Model
hi Tom you kind of need to set the ground rules for this. It's not really practical to use schematron to do detailed terminology validation. Must serious attempts end up creating some kind of web service terminology server that can be invoked from the schematron rules. Once you've done that, you've got a relief valve for things that are too difficult to express in xpath - because xpath is really good for some things, and really not so good for others. But also, once you've done that, you're not really using schematron anymore... Grahame On Tue, Apr 23, 2013 at 8:39 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 23/04/2013 10:37, Bert Verhees wrote: have ADL, AOM, and object transforms What is missing is that xml offers validation and query out of the box, which means it has been developed and optimized for years by many companies and communities, and mostly is good quality software. ok but we just agreed that XSD doesn't do the kind of validation that is needed by archetypes, so I think what you are really proposing is XML based on Relax NG as a sufficiently powerful approach that would a) implement the required constraint semantics of archetypes and b) create data that can be queried by Xpath/Xquery out of the box? Is that your suggestion? If so, my reaction would be: let's investigate as a community. I don't think anyone has sufficiently investigated Relax NG or Schematron for openEHR purposes, and in hindsight we probably should have. It would be very interesting indeed to see how much better it would work than XSD. I think if you make any progress in your work on these questions, let's turn them into specs / guidelines / whatever for general use in openEHR. - thomas __**_ openEHR-technical mailing list openEHR-technical at lists.**openehr.orgopenEHR-technical at lists.openehr.org http://lists.openehr.org/**mailman/listinfo/openehr-** technical_lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au/ +61 411 867 065 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130423/1def1e5c/attachment.html
Trying to understand the openEHR Information Model
On Mon, Apr 22, 2013 at 7:26 PM, Bert Verhees bert.verhees at rosa.nl wrote: Another very important restriction for using XML Schema, in my opinion, is that you cannot have two or more elements with the same name but a different data type. This data type must be in detail the same. XML Schema regards an Element with a Dv_Text as a different datatype from an Element with a Dv_CodedText. Both elements will be called items in an XML schema representing an OpenEhr data structure, and thus is not allowed having them different details in data types. This brought Tim Cook to using the GUIDs in the element-names, which is unworkable in my opinion, and above all, probably unnecessary, because in RelaxNG this restriction does not exist. There are many reasons and benefits to using Type4 UUIDs. I cannot imagine that RelaxNG has any magic to allow global elements to be the same name and have different types or two elements at the same level have different types. Certainly no programming language allows that. There are other approaches that can be used and not use UUIDs. You can nest all of your complexTypes and create VERY wide artifacts. You can use intricate namespacing if you want. Other tricks are also possible, for example augmenting element-names during validation-time, but also that is cumbersome code, and that just for avoiding the problems of an ivory tower stupid W3C standard? Interesting here that you call it a stupid standard and then in a later email you praise it for its industry acceptance. But, the things you continue to call tricks are not tricks, they are features of the standard that are implemented because one or more people presented sufficient use cases. Just because Priscilla Walmsley doesn't bless their use doesn't mean that they are any less valid. So this is indeed an important restriction, which makes the clean use of XML Schema impossible in OpenEhr-rm, or any other ADL based multi level modeling system. Dirty use, tricks, ignoring validation errors, etc of course remain possible. Yes, be specific. You probably can't model an ADL based RM in Haskell or Erlang either. But that doesn't mean they are not useful in multi-level modeling with a functional design. If you goal is to stay with ADL then you have to live with those requirements. I chose not to in MLHIM for all the other benefits that come with adopting XML technologies. There are more restrictions, but less important. For example it is not possible to support the Dv_Time constraint/pattern hh:??:??, same for Dv_DateTime. In the Dv_Date is also a problem, but can be worked around by the alternative rule, but on another way then it is meant to use. There are very clean and efficient ways to allow for partial dates in XML Schema. Anyway, after a few weeks I will probably define the OpenEhr RM and all possible constraints in RelaxNG. I'm not sure why you think RelaxNG will work any better than XML Schema 1.1 This is a three part intro that was published in Jan. 2009: http://www.ibm.com/developerworks/xml/library/x-xml11pt1/index.html --Tim -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130423/e147157a/attachment.html
Trying to understand the openEHR Information Model
name, but a different content/datatype. This is just what is needed to handle the ADL constructs which have the similar characteristics. Why are you angry? If you are satisfied about your solution, if you feel strong about it, what is then your problem? You know the Chinese saying: Let thousand flowers bloom. What makes you angry about my effort to let flowers bloom? Bert -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130423/f3806e9e/attachment-0001.html
Trying to understand the openEHR Information Model
On Tue, Apr 23, 2013 at 3:00 PM, Bert Verhees bert.verhees at rosa.nl wrote: Why are you angry? If you are satisfied about your solution, if you feel strong about it, what is then your problem? You know the Chinese saying: Let thousand flowers bloom. What makes you angry about my effort to let flowers bloom? I am not the slightest bit angry. I was just correcting your incorrect assertions about why I made design choices. If you want to build your openEHR processor in COBOL, I couldn't care less. But when you mention my name or my project specifically and make incorrect assertions I will correct them. Cheers, Tim -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130423/b65387a9/attachment.html
Trying to understand the openEHR Information Model
On 04/23/2013 12:39 PM, Thomas Beale wrote: On 23/04/2013 10:37, Bert Verhees wrote: have ADL, AOM, and object transforms What is missing is that xml offers validation and query out of the box, which means it has been developed and optimized for years by many companies and communities, and mostly is good quality software. ok but we just agreed that XSD doesn't do the kind of validation that is needed by archetypes, so I think what you are really proposing is XML based on Relax NG as a sufficiently powerful approach that would a) implement the required constraint semantics of archetypes and b) create data that can be queried by Xpath/Xquery out of the box? Is that your suggestion? Exactly, that is my idea. I already did that for XML-schema, walking throug AOM-objects, and defining the structure-constraints and leaf-node constraints in XML-schema, but I don't like that very much because of the tricks I need to use. My hope is that Relax NG does not require these kind of tricks. But I am not completely ready studying it, but I found that some important restrictions (concerning the restrictions in structure) of XML Schema do not apply to Relax NG, and I also checked the leaf-node-simple-datatypes, where it seems to allow to define all possible ADL-constraints. So, I can build the structure of an archetype, keeping the paths in original names, keeping the constraints on the structure, and I can apply all leaf-node constraints. But at this moment I am very busy doing something else, and there is (quite) some time-pressure on that, working in the evening, that kind of thing. If so, my reaction would be: let's investigate as a community. I don't think anyone has sufficiently investigated Relax NG or Schematron for openEHR purposes, and in hindsight we probably should have. It would be very interesting indeed to see how much better it would work than XSD. I will write a paper on it, how the structures and leaf-nodes are to be defined in Relax NG and publish that. Maybe there is still something left to ask or discuss, that is always good. It will take a few weeks before I have time for that. And what do I have then ADL - Relax NG conversion - automatic validation based on good quality of code XML-datasets - XQuery - full featured query language. Optional is AQL - XQuery syntax transformation, some people find that important, I think it is possible. In fact, the complete OpenEHR ecosystem ready to work with XML, and almost everything running on matured code. That is the goal. Bert
Trying to understand the openEHR Information Model
On 04/23/2013 08:13 PM, Timothy W. Cook wrote: But when you mention my name or my project specifically and make incorrect assertions I will correct them. That is acceptable, but I thought you were criticizing me, and that is not needed to correct incorrect assertions. That gave me the impression that there was some anger. But I am glad this is not the case. Regards Bert
Trying to understand the openEHR Information Model
On Tue, Apr 23, 2013 at 3:57 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: out of interest Tim, did you look at Releax NG or Schematron? Yes and 1.1 implements everything that RelaxNG and Schematron had to be implemented for in the first place. I wasn't involved but it looks like they took lessons learned from the community quite well. So my position is; why introduce the extra complexity of multiple languages? The lack of support for hh:??:?? is actually the fault of the ISO8601 standard, and I suspect it's because the writers never actually implemented a parser, and had the simple realisation that a partial date or time (e.g. 1995, 12) is impossible to distinguish syntactically from an integer in a mixed data stream - some other help is always needed. Yes, the non-implementable 8601 is an entirely different issue. XML Schema solves it with the data types gMonthDay, gYear etc. Ugly, but not really their fault. The 'g' prefix is non-intuitive. But as you say, they had to implement multiple datatypes to cover the use cases. A slightly better designed 8601 standard would have saved a lot of problems, and the ultimate fault in my view lies at the door of ISO: a completely wrong model of doing standards. The ISO issue is simply one of an organization not adapting to the changing times. It was probably a good model in the early days. But that is common in organizations. People protect their turf in many ways. --Tim -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130423/9d833a73/attachment.html
Trying to understand the openEHR Information Model
Hi Bert,
On Tue, Apr 23, 2013 at 3:00 PM, Bert Verhees 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**
givenNameJohn/givenName** familyNameSmith/familyName**
emailjs at example.com
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org/email**
/card** card** nameFred Bloggs/name** emailfb at
example.net
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org/email**
notebla 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.
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.
Cheers,
Tim
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130423/9359da8e/attachment.html
Trying to understand the openEHR Information Model
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
// givenNameJohn/givenName
// familyNameSmith/familyName
// emailjs at example.com
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org/email
///card
//card
// nameFred Bloggs/name
// emailfb at example.net
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org/email
// notebla 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
