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 5:5
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 t
;)
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 choos
;)
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 choos
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:
...
Heath
On Nov 28, 2012 9:07 AM, "Bert Verhees" wrote:
>
>
> Verstuurd vanaf mijn iPad
>
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"
wrote:
> I'll attempt to comment on Bert's problem, hop
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 :
> Hi!
>
> I see several use cases for sending and storing XML pieces smaller
> than compositions etc as valid XML documents.
>
> What about creat
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 clarif
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 that
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 r
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
Bert Verhees wrote:
> I don't have a Jira account at your site, if I have, I post my XSD's as a
> proposition.
Hi Bert,
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 ov
CLUSTER for one. The XML ITS of the RM is not a pure representation of the
RM. Design decisions needed to be made, this is one of them. If you have a
problem with it raise a jira issue.
Heath
On Nov 28, 2012 5:55 AM, "Bert Verhees" wrote:
>
>
> Verstuurd vanaf mijn iPad
>
> Op 27 nov. 2012 om 20:
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 different
Bert,
Items is not a class, it is an attribute.
Heath
On Nov 27, 2012 8:50 PM, "Bert Verhees" 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 intent of the ite
Hi Heath, take a look at items in CLUSTER, it is declared as a local element.
Bert
Verstuurd vanaf mijn iPad
Op 27 nov. 2012 om 20:47 heeft Heath Frankel het volgende geschreven:
> CLUSTER for one. The XML ITS of the RM is not a pure representation of the
> RM. Design decisions needed to be m
Verstuurd vanaf mijn iPad
Op 27 nov. 2012 om 20:24 heeft Heath Frankel 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 concrete classes can be instantiated in X
thanks, Peter, I will work on it tomorrow.
Bert
Verstuurd vanaf mijn iPad
Op 27 nov. 2012 om 23:06 heeft Peter Gummer 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.
>
>
>
> Hi Bert,
>
> From th
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 v
" 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
iPad
Verstuurd vanaf mijn iPad
Op 27 nov. 2012 om 20:13 heeft Heath Frankel 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 attribute?
Bert
> Heath
>
> On Nov
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" 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 intent of the items
> element, to allow any rotatable concrete type to be represented in a
> document with root element of ite
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
On 11/27/2012 04:26 AM, Thomas Beale wrote:
> 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,
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
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
w
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" het volgende geschreven:
> Hi Bert,
>
> Sorry but I struggled to understand the issue you have below. Would you mind
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 he
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
wrote:
> Hi Seref,
>
> The openEHR schemas have been there for many years.
> http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html
>
>
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 het volgende geschreven:
> Greetings,
> Did I get th
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 si
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
>
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 :
> Hi,
>
> I was studying the OpenEHR XSD files, I found they validate fine again
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.
I commented it out, and it still validates fine.
2)
There were some mor
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
openEH
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
>
38 matches
Mail list logo
