Bert,
Items is not a class, it is an attribute.
Heath
On Nov 27, 2012 8:50 PM, Bert Verhees bert.verhees at rosa.nl wrote:
Op 27-11-2012 9:07, Heath Frankel schreef:
Bert,
You can define elements to be type of an abstract type allowing any
concrete subtype in an instance. This is the
Bert,
The rule you reference says nothing about concrete types. As far as I am
concerned the items element is satisfying this rule.
You are welcome to change the schema in your system as you see fit just as
linkEHR have done, but I suggest any additional element declarations are
done in a
thanks, Peter, I will work on it tomorrow.
Bert
Verstuurd vanaf mijn iPad
Op 27 nov. 2012 om 23:06 heeft Peter Gummer peter.gummer at
oceaninformatics.com het volgende geschreven:
Bert Verhees wrote:
I don't have a Jira account at your site, if I have, I post my XSD's as a
proposition.
Verstuurd vanaf mijn iPad
Op 27 nov. 2012 om 20:24 heeft Heath Frankel heath.frankel at
oceaninformatics.com het volgende geschreven:
Bert,
The rule you reference says nothing about concrete types. As far as I am
concerned the items element is satisfying this rule.
Hi Heath, only
Seref,
The items element is provided in the structure.xsd for this very reason but
Bert seems to object to it because of its name or its type or some other
reason that I have not yet determined.
Heath
On Nov 28, 2012 7:42 AM, Seref Arikan serefarikan at kurumsalteknoloji.com
wrote:
I'll attempt
True, but you can declare elements in an xsd as an abstract type allowing
any concrete type to be provided in an xml document where the concrete type
is specified using the xs:type attribute. For example:
oe:items xs:type=oe:ITEM_TREE xmlns:oe=... xmlns:xs=...
archetype_node_id=..oe:items
On 11/28/2012 02:35 AM, Heath Frankel wrote:
Seref,
The items element is provided in the structure.xsd for this very
reason but Bert seems to object to it because of its name or its type
or some other reason that I have not yet determined.
I give up, I don't know what is happening over
On 11/27/2012 10:42 PM, Seref Arikan wrote:
I'll attempt to comment on Bert's problem, hoping I understand it :)
When you do not have a root element definition in an XSD, you can't
create XML documents which will be valid according to that XSD. What
Bert is saying is, if we had a bunch of
On 11/27/2012 10:42 PM, Seref Arikan wrote:
I'll attempt to comment on Bert's problem, hoping I understand it :)
When you do not have a root element definition in an XSD, you can't
create XML documents which will be valid according to that XSD. What
Bert is saying is, if we had a bunch of root
Hi!
I see several use cases for sending and storing XML pieces smaller
than compositions etc as valid XML documents.
What about creating a separate (but official) file with those root
elements in the same namespace as the other schema components? That
way implementers can choose if they want
On 11/28/2012 09:46 AM, Erik Sundvall wrote:
P.s. Bert, I think you may have interpreted the tone of some
comments/replies as more hostile than they were intended by the
senders. It is sometimes hard to understand what you and others asking
for so it takes some rounds of questions to clarify
I didn't realize that the XSD file has no license. Please assume a
CC-BY license, which is the same we use for 13606 schemas.
2012/11/28 Erik Sundvall erik.sundvall at liu.se:
Hi!
I see several use cases for sending and storing XML pieces smaller
than compositions etc as valid XML documents.
Bert,
I too was sharing my knowledge, as one of the authors of the schema whether
they are classed as good or bad, I thought it was worth the effort
explaining the design rationale.
I apologise for wasting your time and will choose more wisely in future
where I spend mine.
Heath
On Nov 28, 2012
;)
Bert
On 11/28/2012 12:01 PM, Heath Frankel wrote:
Bert,
I too was sharing my knowledge, as one of the authors of the schema
whether they are classed as good or bad, I thought it was worth the
effort explaining the design rationale.
I apologise for wasting your time and will choose
;)
Bert
On 11/28/2012 12:01 PM, Heath Frankel wrote:
Bert,
I too was sharing my knowledge, as one of the authors of the schema
whether they are classed as good or bad, I thought it was worth the
effort explaining the design rationale.
I apologise for wasting your time and will choose
I'm unclear on the outcome of this confusing discussion. For the lack of
demographic XSD, what should be used is an XSD that is compatible with
the existing ones. For the other questions, they're at a level of detail
I don't know in XSD. But they should be answerable one way or the other.
So
Hi Seref
Only one XSD set from openEHR. If we upgrade it has to be formal.
Cheers, Sam
On 27/11/2012 2:43 AM, Seref Arikan wrote:
Greetings,
Did I get this right? There are XSDs on openEHR web site. There are
also XSDs which are different than the first set, provided by LinkEHR.
If these are
Sent: Tuesday, 27 November 2012 3:07 AM
To: For openEHR technical discussions
Subject: Questions about the XSD-files.
Hi,
I was studying the OpenEHR XSD files, I found they validate fine against
Saxon-EE 1.0 and 1.1
But I have a few points which are not clear to me.
1)
In the Structure.xsd I
Verstuurd vanaf mijn iPad
(I leave this notice so people understand the torture I went through, while
replying to this email)
Op 26 nov. 2012 om 23:58 heeft Heath Frankel heath.frankel at
oceaninformatics.com het volgende geschreven:
Hi Bert,
Sorry but I struggled to understand the
On 26/11/2012 17:02, Bert Verhees wrote:
Thanks Athanasios and Diego,
It is easier to download then to write it myself ;-)
But still I wonder why the OpenEHR-community is not offering these.
I think it just did ;-)
Early in 2013, the specifications will be start being revamped. That
will
Bert,
You can define elements to be type of an abstract type allowing any
concrete subtype in an instance. This is the intent of the items element,
to allow any rotatable concrete type to be represented in a document with
root element of items.
Heath
On Nov 27, 2012 6:19 PM, Bert Verhees
Op 27-11-2012 9:07, Heath Frankel schreef:
Bert,
You can define elements to be type of an abstract type allowing any
concrete subtype in an instance. This is the intent of the items
element, to allow any rotatable concrete type to be represented in a
document with root element of items.
Verstuurd vanaf mijn iPad
Op 27 nov. 2012 om 20:13 heeft Heath Frankel heath.frankel at
oceaninformatics.com het volgende geschreven:
Bert,
Items is not a class, it is an attribute.
exactly my idea, it is not an attribute in XSD context, but in class context.
from which class is it an
i am still not understanding you issues with this element other than styling.
If you have any technical issue please raise a jira issue
I still don't understand what humanity did wrong that we need to be punished
with iPads, my wife remove all computers from the living space, and bought
I'll attempt to comment on Bert's problem, hoping I understand it :)
When you do not have a root element definition in an XSD, you can't create
XML documents which will be valid according to that XSD. What Bert is
saying is, if we had a bunch of root elements in the XSDs, it would allow
us create
Hi,
I was studying the OpenEHR XSD files, I found they validate fine against
Saxon-EE 1.0 and 1.1
But I have a few points which are not clear to me.
1)
In the Structure.xsd I find this line, I don't know why it is there.
xs:element name=items type=LOCATABLE/
I commented it out, and it still
Hello Bert,
We created a XML Schema for the demographics part some time ago. You
can download it from here.
http://pangea.upv.es/linkehr/wp-content/uploads/2009/03/Demographics.xsd
Regards
2012/11/26 Bert Verhees bert.verhees at rosa.nl:
Hi,
I was studying the OpenEHR XSD files, I found
Dear Bert
As far as (4) is concerned, i have been using linkEHR's XSD from:
http://pangea.upv.es/linkehr/?page_id=10
hope this helps
All the best
Athanasios Anastasiou
On 26/11/2012 16:36, Bert Verhees wrote:
Hi,
I was studying the OpenEHR XSD files, I found they validate fine against
Thanks Athanasios and Diego,
It is easier to download then to write it myself ;-)
But still I wonder why the OpenEHR-community is not offering these.
cheers
Bert
On 11/26/2012 05:51 PM, Diego Bosc? wrote:
Hello Bert,
We created a XML Schema for the demographics part some time ago. You
Greetings,
Did I get this right? There are XSDs on openEHR web site. There are also
XSDs which are different than the first set, provided by LinkEHR.
If these are XSDs of the published parts of the openEHR specifications,
such as RM or AOM, then there should only be one XSD set, published by
Hi Seref,
The XML Schema standard 1.1 has no problem with having multiple files for one
definition-set. You can find them linked from the specifications-1.0.2-page.
Bert
Verstuurd vanaf mijn iPad
Op 26 nov. 2012 om 18:13 heeft Seref Arikan serefarikan at
kurumsalteknoloji.com het volgende
Hi Seref,
The openEHR schemas have been there for many years.
http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html
--Tim
On Mon, Nov 26, 2012 at 3:13 PM, Seref Arikan
serefarikan at kurumsalteknoloji.com wrote:
Greetings,
Did I get this right? There are XSDs on openEHR web site.
I think I misunderstood the original question. Thanks for all the responses
everyone.
Best regards
Seref
On Mon, Nov 26, 2012 at 8:16 PM, Timothy Cook
timothywayne.cook at gmail.comwrote:
Hi Seref,
The openEHR schemas have been there for many years.
Hi Sam and Seref,
Both of you indicate that maintenance of the XSD has to be done formally by the
foundation.
This good news, then there will be only a single answer possible for the four
questions I started this thread with.
thanks,
Bert
Verstuurd vanaf mijn iPad
Op 26 nov. 2012 om 22:46
34 matches
Mail list logo
