[wfs-dev] null values
Andreas v.Dömming
v.doemming at tuhh.de
Tue Oct 31 18:34:24 EST 2006
Hi John,
I did not want to preserve "offset" in the list. The intention in the example
was to preserve the sequence of ordered items (e.g. pages in a book),
allthough some of them are not available at parsing time (probably for some
unknown reason).
Assuming that order matters these items should not be dropped (option#2) as
this would not keep the position-in-document of the other items. Also they
should not occur as empty elements cause unavailable!=empty (#1).
So last option was xsi:nil="true" (#3) encoding, which keeps element order but
does not provide any content for the unavailable item.
I fully agree that the meaning of "order" is not explicitly expressed by the
schema and this might result in interoperability problems because of this
illegal assumption. Thank you for clarification.
IMHO, there is no possibility to express this in the XML-Schema.
I found an interresting article "When the order of XML elements matters":
http://www-128.ibm.com/developerworks/xml/library/x-eleord.html
Regards,
Andreas
Am Montag, 30. Oktober 2006 15:01 schrieb John Herring:
> Andreas,
> Actually, your example worries me more than the
> original question at hand.
>
> > Assume you have a list of 2 properties in your data
> > model, null-values should be allowed, but also the
> > order of the values has a meaning.
> > Here you can not use minOccurs="0" because you
> > will loose the value's order.
>
> Now I am not an immediate nor great believer in XML,
> but I will be the first to admit that it has its good
> points. One of the most important is that the semantics of
> the data is clearly labeled in such a manner that it is hard
> to misinterpret the data. (I won't say foolproof since we
> are always coming up with more inventive fallacies and
> better fools every day, ain't progress marvelous B^}) This
> means, among other things, that it is antithetical to use
> XML is a non-obvious manner. In this case in point, the use
> of order to signify a hidden meaning not expressed in or by
> the labels and their associated attributes.
>
> Again, I am at a lost to understand why preserving
> "offset" in a list
> (ordering is actually a different issue)
> unless the target application is blindly loading the list
> into a set of data slots with specific meanings not
> reflected in the XML's structure. This almost sounds like
> the distinction between encoding and encryption. If
> something is going on that requires understanding offset in
> a list to understand the data but is represented and not
> present in the XML <tags/> and their associated attributes,
> then we are speaking of the ultimate of tightly bound
> applications and the antithesis of service oriented
> architecture (SOA).
>
> The advantage of using the GML "something or NULL"
> data types is that the transparency of meaning is
> maintained. This transparency support understanding and
> suppressing misinterpretation to a degree. What you are
> suggesting is cutting very close to the heart of XML's
> ability to support interoperability through loose coupling
> in an SOA environment.
>
> But then maybe I misunderstood your meaning?
>
> Regards,
> John
>
> You do what you can when you can because you can.
>
> The opinions expressed in this email are purely my own and
> do not necessarily represent the opinions of any
> organization
> or otherwise sane person or persons.
>
> John R. Herring
> Architect, Spatial Products
> Oracle Corporation
> One Oracle Drive
> Nashua, New Hampshire 03062
> ph: 1 603 897 3216
> fx: 1 603 897 3334
>
> Annue cœptis - Novus Ordo Seclorum
>
>
> -----Original Message-----
> From:
> wfs-dev-bounces+john.herring=oracle.com at opengeospatial.org
> [mailto:wfs-dev-bounces+john.herring=oracle.com at opengeospati
> al.org] On Behalf Of Andreas v.Dömming
> Sent: Monday, October 30, 2006 5:14 AM
> To: wfs-dev at opengeospatial.org
> Subject: Re: [wfs-dev] null values
>
> John, list
>
> thinking about use-cases where "nillable" is needed I found
> this:
> Assume you have a list of 2 properties in your data model,
> null-values should be allowed, but also the order of the
> values has a meaning.
> Here you can not use minOccurs="0" because you will loose
> the value's order.
>
> <FeatureA>
> <orderedEntry>value<orderedEntry/>
> <!-- is the first or the second orderedEntry a null-value
> ?--> </FeatureA>
>
> But you can enforce to keep the order by using the
> nillable-attribute:
>
> <xs:element name="orderedEntry" minOccurs="2" maxOccurs="2"
> nillable="true"
> type="xs:string">
>
> <FeatureA>
> <orderedEntry xs:nil="true"/>
> <orderedEntry>value<orderedEntry/>
> </FeatureA>
>
> Nevertheless, I agree that in most use-cases the
> minOccurs="0" is the better choice. But depending on the
> model it is not allways possible.
>
> Regards,
> Andreas
>
> Am Freitag, 27. Oktober 2006 16:52 schrieb John Herring:
> > Bart,
> > I have a problem with "nillable". See XML Schema,
>
> Part 1, Section
>
> > 3.3.3, bullet 2.2 at
> > http://www.w3.org/TR/xmlschema11-1/#d0e5913
> >
> > If I am reading this right, if you use a "ref" (a
>
> global element
>
> > specification) to specify a subelement of a type in a
>
> schema, then
>
> > "nillable" cannot be used, and your only shot at NULL
>
> versus NOT NULL
>
> > is "minOccurs=0". Which means that any concept of a
>
> nillable
>
> > subelement of a feature must be included in any global
>
> definition of
>
> > the original element, not specified differently for
>
> different uses.
>
> > That sounds a little off, and consideration the
>
> times we naturally
>
> > use ref in application schemas, a bit dangerous.
> >
> > Regards,
> > John
> >
> > You do what you can when you can because you can.
> >
> > The opinions expressed in this email are purely my own and
>
> do not
>
> > necessarily represent the opinions of any organization or
>
> otherwise
>
> > sane person or persons.
> >
> > John R. Herring
> > Architect, Spatial Products
> > Oracle Corporation
> > One Oracle Drive
> > Nashua, New Hampshire 03062
> > ph: 1 603 897 3216
> > fx: 1 603 897 3334
> >
> > Annue cœptis - Novus Ordo Seclorum
> >
> >
> > -----Original Message-----
> > From: Bart van den Eijnden (OSGIS)
>
> [mailto:bartvde at osgis.nl]
>
> > Sent: Friday, October 27, 2006 10:31 AM
> > To: John Herring; 'Bart van den Eijnden OSGIS';
> > wfs-dev at opengeospatial.org
> > Subject: RE: [wfs-dev] null values
> >
> > Hi John,
> >
> > I think XMLSchema deals with this by having the minOccurs
>
> as well as
>
> > the nillable attribute on an element.
> >
> > So minOccurs="1" nillable="false" would mean NOT NULL.
> >
> > Best regards,
> > Bart
> >
> > --
> > Bart van den Eijnden
> > OSGIS, Open Source GIS
> > http://www.osgis.nl
> >
> >
> > --------- Oorspronkelijk bericht --------
> > Van: John Herring <john.herring at oracle.com>
> > Naar: 'Bart van den Eijnden OSGIS' <bartvde at osgis.nl>,
> > wfs-dev at opengeospatial.org <wfs-dev at opengeospatial.org>
> > Onderwerp: RE: [wfs-dev] null values
> > Datum: 27/10/06 11:36
> >
> > > Bart,
> > >
> > > Most systems have their own way of dealing with
> >
> > NULLs. In XML is
> >
> > > seems to be simply leaving out the element.
> > > Which leads to an interesting philosophic question about
> >
> > your
> >
> > > proposal.
> > >
> > > If one writes:
> > >
> > > <MYFIRSTITEM>aaa</MYFIRSTITEM>
> > > <PRIORITY/>
> > > <MYTHIRDITEM>zzz</MYTHIRDITEM>
> > >
> > > And the original schema calls for PRIORITY's
> >
> > minOccurs to be 1, have
> >
> > > you violated the intent of the schema? In SQL you get to
> >
> > put in
> >
> > > "NOT NULL" and in XML you get to put in
> > > "minOccurs=1" and force a value. In either of
> >
> > your
> >
> > > suggestions with a PRIORITY element, you are not in
> >
> > violation of a
> >
> > > "minOccurs=1" but you are in violation of the
> >
> > semantics of
> >
> > > not allowing a NULL.
> > >
> > > Personally, I thing that IONIC is right and the only
> >
> > way to do this
> >
> > > is the way the XML gurus meant us to do it, which is
>
> with
>
> > minOccurs=0
> >
> > > and missing elements. On the other hand, GML's multiple
> >
> > flavors of
> >
> > > NULL does something else altogether, but at least you
>
> can
>
> > force an
> >
> > > application schema not to use it (the equivalent of a
>
> NOT
>
> > NULL).
> >
> > > Regards,
> > > John
> > >
> > > You do what you can when you can because you can.
> > >
> > > The opinions expressed in this email are purely my own
>
> and
>
> > do not
> >
> > > necessarily represent the opinions of any organization
>
> or
>
> > otherwise
> >
> > > sane person or persons.
> > >
> > > John R. Herring
> > > Architect, Spatial Products
> > > Oracle Corporation
> > > One Oracle Drive
> > > Nashua, New Hampshire 03062
> > > ph: 1 603 897 3216
> > > fx: 1 603 897 3334
> > >
> > > Annue cœptis - Novus Ordo Seclorum
> > >
> > >
> > > -----Original Message-----
> > > From:
>
> wfs-dev-bounces+john.herring=oracle.com at opengeospatial.org
>
>
> [mailto:wfs-dev-bounces+john.herring=oracle.com at opengeospati
>
> > > al.org] On Behalf Of Bart van den Eijnden (OSGIS)
> > > Sent: Friday, October 27, 2006 9:06 AM
> > > To: wfs-dev at opengeospatial.org
> > > Subject: [wfs-dev] null values
> > >
> > > Hi list,
> > >
> > > how is a WFS supposed to deal with null values?
> > >
> > > I can see 3 options (for instance an attribute named
> > > PRIORITY):
> > >
> > >
> > > 1) just output an empty element (I guess not the
>
> cleanest
>
> > approach
> >
> > > since it cannot be distinguished from an empty
> > > string)
> > >
> > > <MYFIRSTITEM>aaa</MYFIRSTITEM>
> > > <PRIORITY></PRIORITY>
> > > <MYTHIRDITEM>zzz</MYTHIRDITEM>
> > >
> > > I think this is how Mapserver WFS operates.
> > >
> > >
> > > 2)
> > > Leave out the respective element in the reponse.
> > >
> > > <MYFIRSTITEM>aaa</MYFIRSTITEM>
> > > <MYTHIRDITEM>zzz</MYTHIRDITEM>
> > >
> > > This is what Ionic WFS does.
> > >
> > > 3)
> > > An option I have not yet seen, output
> >
> > xsi:nil="true" for the
> >
> > > respective element?
> > >
> > > <MYFIRSTITEM>aaa</MYFIRSTITEM>
> > > <PRIORITY
>
> xsi:nil="true"></PRIORITY>
>
> > > <MYTHIRDITEM>zzz</MYTHIRDITEM>
> > >
> > > Ofcourse the 1) and 3) behaviour is easier to process
>
> (for
>
> > instance
> >
> > > with
> > > XSLT) than the second one.
> > >
> > > Should the WFS spec say something about this? Or is it
>
> up
>
> > to the
> >
> > > vendor? It would make life easier if they all did the
>
> same
>
> > thing IMHO.
> >
> > > And I guess 3) is the cleanest approach.
> > >
> > > Thanks in advance for any input on this.
> > >
> > > Best regards,
> > > Bart
> > >
> > > --
> > > Bart van den Eijnden
> > > OSGIS, Open Source GIS
> > > http://www.osgis.nl
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > wfs-dev mailing list
> > > wfs-dev at opengeospatial.org
> > > https://mail.opengeospatial.org/mailman/listinfo/wfs-dev
> >
> > _______________________________________________
> > wfs-dev mailing list
> > wfs-dev at opengeospatial.org
> > https://mail.opengeospatial.org/mailman/listinfo/wfs-dev
>
> _______________________________________________
> wfs-dev mailing list
> wfs-dev at opengeospatial.org
> https://mail.opengeospatial.org/mailman/listinfo/wfs-dev
More information about the wfs-dev
mailing list