[no subject]

This problem belongs to the same category as having too many optional
elements. At implementation time, depending on the requirements, you'll
probably end up tightenning the schema up a little bit to specify exactly
which elements are optional and which are compulsory, depending on the
requirements.

This is especially the case if you need to use the schema for XML validation
purposes. Validating against standard xNAL schema would certainly not be
sufficient to most applications. Manually (programmatically) validating XML
elements is also not a good option. Therefore some changes to the schema
itself are inevitable.


Regards,


 
-- 
Hido Hasimbegovic
eBusiness Consultant | CustomWare Asia Pacific | www.customware.net
T: +61-3-9667-0124 | F: +61-3-9663-2616 | M: +61-416-174-453
Level 2, 222 Latrobe Street
Melbourne VIC 
3000 Australia
 
Improve the quality of your services with WmUnit
 
Unit testing framework for WebMethods http://www.customware.net/WmUnit
 
 
 
-----Original Message-----
From: Ram Kumar [mailto:RKumar@msi.com.au] 
Sent: Wednesday, 25 August 2004 9:36 AM
To: ciq@lists.oasis-open.org
Subject: [ciq] FW: xNAL schemas

From: Paul Spencer [mailto:paul.spencer@boynings.co.uk] 
Sent: Tuesday, August 24, 2004 7:51 PM
To: Ram Kumar
Subject: FW: xNAL schemas

Ram,

Thinking more, I suspect I was wrong - since the xAL schema is imported
into
the EML schema, it is the target namespace of xAL that the "other"
refers
to.

I guess I am just having a bad morning.

Regards

Paul

-----Original Message-----
From: Paul Spencer [mailto:paul.spencer@boynings.co.uk]
Sent: 24 August 2004 10:11
To: rkumar@msi.com.au
Subject: xNAL schemas


Hi Ram,

As you know, we are using the xNAL schemas in the OASIS Election Markup
Language. I think I have come across a problem.

In EML, we have several different types of addresses. We have given each
of
these its own data type. In some national versions, these are cast to
different data types, but in the International version, they are all
xal:AddressDetails:

<xs:complexType name="MailingAddressStructure">
  <xs:complexContent>
    <xs:extension base="xal:AddressDetails"/>
  </xs:complexContent>
</xs:complexType>
<xs:complexType name="PhysicalAddressStructure">
  <xs:complexContent>
    <xs:extension base="xal:AddressDetails"/>
</xs:complexContent>
etc.

xal:AddressDetails has two optional items (xal:PostalServiceElements and
an
xs:choice) followed by an optional xs:any namespace="##other".

I believe that, unless the target namespace of the containing schema is
the
xAL namespace, this makes the schema non-deterministic since, say, the
xal:PostalServiceElements element could be part of either the branch
with
its name or the xs:any branch.

Unfortunately, schema processors are notoriously bad at detecting
non-deterministic schemas, so this is difficult to test.

Do you have any comments? It could be that I have read this wrongly.

Regards

Paul Spencer
Director
Boynings Consulting Ltd
http://www.boynings.co.uk


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/ciq/members/leave_workgroup.php
.