xsl-list
[Top] [All Lists]

Re: [xsl] XML-Schema (W3C) mailing list?

2010-12-26 23:14:36
Hi Wolfgang,

Thanks for your detailed answer!

On Fri, 2010-12-24 at 08:05 +0100, Wolfgang Laun wrote:
You could ask questions such as this one on the JAXB user list
http://java.net/projects/jaxb/lists/  users(_at_)jaxb(_dot_)java(_dot_)net or 
on
http://www.codesynthesis.com/mailman/listinfo/xsd-users

Since I'm going to mention XSLT in answering your question, I might as
well provide an answer here ;-)

The short answer is simple: XML Schema driven parsing of XML documents
depends on element names, not even on present or absent attribute
names, and certainly not at all on attribute values. Values may be
checked by validation against an XML Schema, but there is no way of
expressing that children must have  @type="x" iff parent has
@type="x".

Is there some official document which gives general guidelines about the
parsing algorithm to be used for XML Schemata together with some notes
about the consequences these guidelines have concerning the best way to
encode information in XML?  I would like to persuade the side producing
the data to use some different format in the future...

It's easy to write an XSLT stylesheet doing this check.

It's also not difficult to write a transformation converting the
original XML to a well structured one (according to one of your
ideas), and then you can write an XML schema which is capable of
generating Java or C++ code for typesafe unmarshalling.

Or you disregard the dependencies; write the XML schema based on the
original structure and do the (simple) check after unmarshalling.

Thank you very much.  So for the time being I will use XSLT to bring the
data into a more adequate format and try to influence the people
producing the data to use this format from now on.

Am I right that a structure like 

  <aList>
    <aItem></aItem>
    <aItem></aItem>
    <aItem></aItem>
    ...
  </aList>

  <bList>
    <bItem></bItem>
    <bItem></bItem>
    <bItem></bItem>
    ...
  </bList>

where all necessary distinctions are encoded in the element names would
be the best in this case?

Thank you very much for your help,

Dietrich


HTH
-W

On 24 December 2010 06:17, Dietrich Bollmann <diresu(_at_)web(_dot_)de> wrote:

Hi,

Is there a mailing list for asking questions concerning the usage of
XML-Schemata (W3C) ?

Thanks,

Dietrich


PS: For any case, I append the question I would like to ask:

---
Subject:  Is there a way to control child element selection depending on
some parent attribute value?

Hi,

I was asked to implement an XML-Schema
for a sequence made from

 <list type="a"></list>
 <list type="b"></list>

in any order, for example

 <sequence>
   <list type="a"></list>
   <list type="b"></list>
   <list type="b"></list>
   <list type="a"></list>
   <list type="b"></list>
   ...
 </sequence>

each list looking like the following:

 <list type="a">
   <item type="a"></item>
   <item type="a"></item>
   <item type="a"></item>
   ...
 </list>

or

 <list type="b">
   <item type="b"></item>
   <item type="b"></item>
   <item type="b"></item>
   ...
 </list>

I suppose a better way to implement this would be by rather using
elements like:

 <aList></aList>
 <bList></bList>

together with

 <aList>
   <item type="a"></item>
   <item type="a"></item>
   <item type="a"></item>
   ...
 </aList>

and

 <bList>
   <item type="b"></item>
   <item type="b"></item>
   <item type="b"></item>
   ...
 </bList>

or even

 <aList>
   <aItem></aItem>
   <aItem></aItem>
   <aItem></aItem>
   ...
 </aList>

and

 <bList>
   <bItem></bItem>
   <bItem></bItem>
   <bItem></bItem>
   ...
 </bList>

But unfortunately I don't control the source XML files...

The latter is easy to implement:

   <xs:element name="sequence">
     <xs:complexType>
       <xs:choice maxOccurs="unbounded">
         <xs:element name="aList" type="aItemList"/>
         <xs:element name="bList" type="bItemList"/>
       </xs:choice>
     </xs:complexType>
   </xs:element>

but when trying to implement the original proposal with something like:

   <xs:element name="sequence">
     <xs:complexType>
       <xs:choice maxOccurs="unbounded">
         <xs:element name="list">
           <xs:complexType>
             <xs:attribute name="type" use="required">
               <xs:simpleType>
                 <xs:restriction base="xs:string">
                   <xs:enumeration value="a"/>
                 </xs:restriction>
               </xs:simpleType>
             </xs:attribute>
           </xs:complexType>
         </xs:element>
         <xs:element name="list">
           <xs:complexType>
             <xs:attribute name="type" use="required">
               <xs:simpleType>
                 <xs:restriction base="xs:string">
                   <xs:enumeration value="b"/>
                 </xs:restriction>
               </xs:simpleType>
             </xs:attribute>
           </xs:complexType>
         </xs:element>
       </xs:choice>
     </xs:complexType>
   </xs:element>

--- both alternatives are using the same element name "list" and only
differ concerning the allowed values of attribute "type": "a" in the
first case, "b" in the latter one --- the schema parser always takes the
first alternative and complaints about the value of the "type" attribute
when not corresponding to the one specified in the first alternative...

When on the other side allowing both values --- "a" as well as "b" ---
for the "type" attribute of the "list" element

   <xs:element name="foo">
     <xs:complexType>
       <xs:sequence>
         <xs:element name="list" maxOccurs="unbounded">
           <xs:complexType>
             <xs:attribute name="type" use="required">
               <xs:simpleType>
                 <xs:restriction base="xs:string">
                   <xs:enumeration value="a"/>
                   <xs:enumeration value="b"/>
                 </xs:restriction>
               </xs:simpleType>
             </xs:attribute>
           </xs:complexType>
         </xs:element>
       </xs:sequence>
     </xs:complexType>
   </xs:element>

there seems to be no way to control the "type" value of the "item"
elements inside the "list" in order to make them match the one of the
"list" parent element.  The result is, that the whole approach to
control the elements via the "type" attribute doesn't work at all...

I think this is an implementation decision, as the implementation of a
parser with some king of backtracking or looking forward mechanism would
be much less efficient than one which is based on the supposition, that
all alternative inside of <xs:choice/> have different names and solely
decides based on this criteria.

Still, as I don't control the source documents, I wonder, if there is
some way to implement this kind of restriction using XML Schema...

Thanks for the help,

Dietrich






--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--




--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>