OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-ndrsc] Fw: [ubl-lcsc] Elements With Empty Content


At 09:30 AM 7/23/2003 -0500, Lisa-Aeon wrote:
>Another comment from Chee-Kai.
>
>----- Original Message -----
>From: "Chin Chee-Kai" <cheekai@softml.net>
>To: "UBL LCSC" <ubl-lcsc@lists.oasis-open.org>
>Sent: Tuesday, July 22, 2003 10:52 PM
>Subject: [ubl-lcsc] Elements With Empty Content
>
>
> > Stephen brought up during last night's (or morning's) call
> > about addressing the above in LC.  Just to provide a context
> > in preparation for Montreal's discussion.
> >
> > To start off, my attempt to describe terminologies so that
> > we're talking about the same things or concepts:


I think these definitions go too far and don't make the typical 
distinctions. You have two conditions that seem to be in conflict or under 
discussion in term so of empty elements.

You have elements in the document with no content (when defined to have 
content) and you have elements defined as being EMPTY in the schema and 
their required representation as empty. The only way to tell the difference 
is to look at the schema definition. The xsi:nil and nillable are 
attributes needed because of the way schemas went about their design, they 
are controls on elements of types other than string and are just additional 
control.



> >
> > "empty content" = Empty string in the document instance space.
> >                   Examples are (in a document instance):
> >                   <Building></Building>   or <Building/>
> >
> > "nil content"   = Nothing, not even empty content, in the
> >                   document instance space.
> >                   This, in XML Schema, can only be positively
> >                   represented as "xsi:nil".
> >                   Alternatively, it can be negatively represented
> >                   by detecting an absence of instance element
> >                   when the corresponding schema type has a
> >                   maxOccurs of 1 or more.
> >
> > "empty element" = An element with empty content in the document
> >                   instance space.  An element in a document
> >                   instance is said to be an empty element if
> >                   and only if it has empty content.
> >
> > "emptiable schema element"= An element defined or declared within
> >                   the schema space that has a simpleType which
> >                   is ultimately derived from xsd:string.
> >
> > "nillable schema element"= An element defined or declared within
> >                   the schema space that has minOccurs set to 0.
> >
> > Ok, so much for now to start off.  (Feel free to comment on
> > the descriptions above as well if they're source of disagreement).
> >
> > Before we even ask should we allow or disallow empty content
> > elements, a few related questions are:
> >
> > - Are empty elements required in real world?
> >   Are we able determine a-priori that no one ever will need emp


Some design styles require their use. So maybe UBL provided schemas will 
never use EMPTY elements, I don't think we can restrict the end user on 
this one.



> >
> > - Assuming it doesn't, that empty elements aren't required
> >   in the real world, what happens when a user case does
> >   require empty elements?
> >
> >   Otherwise, - What does it mean to instantiate an empty element?
> >
> > - Legal implications of instantiating an empty element.
> >   What legal meanings are associated with saying "I'm stating
> >   an empty value" versus "No, I didn't state anything, not even
> >   saying I have an empty value".


This is why the ACORD spec started out by not allowing elements requiring 
data  to be sent empty. We did actually find a reason for sending empty 
elements for a specific set of messages, but we are actually pulling those 
back and hope to find a better design.


> >
> >   During a discussion in LC about the same topic, a note from
> >   Alan Stitzer was: ACORD disallows empty elements to make
> >   instances more meaningful.
> >   (I haven't got to read the ACORD specs so can't provide more
> >   details)


I work for ACORD and Alan is one of our members. The ACORD specs do not 
allow empty elements when the element is defined to have content (string, 
decimal, etc) but we do use elements defined as EMPTY with attributes that 
before linking for relationships between objects. Typically the attributes 
(or some of them) are required and the only real purpose of these EMPTY 
declared elements is for linking we have not used a pure anchor/trigger 
sort of use.


> >
> > - From a generalist viewpoint, if empty elements are allowed to
> >   be instantiated with a view that legal implications are
> >   addressed (not necessarily resolved), what other conditions
> >   or rules must be appended to make empty elements meaningfully
> >   different from uninstantiated elements of the same
> >   schema element?
> >
> > - What about empty elements that are not emptiable schema elements?
> >
> > - Since "xsi:nil" is not to be used according to NDR [R 94]
> >   (equivalent to [R 32]), should all schema elements be made
> >   nillable schema elements to allow the possibility that
> >   elements can be "skipped" and not instantiated in the instance
> >   space?


This is what you would have to do to allow an element defined to have data 
(other than strings) to be sent empty in the data stream. In general I 
think we shouldn't allow this in UBL schemas or user extended. But as even 
ACORD found a need for this, there might not be any other way around this 
depending upon a users design. In our case we had amended our rule and 
defined what an empty data element meant in the case of these specific 
messages. So we didn't have a general description of what the empty 
situation meant, it was only described in terms of this one message.

..dan


> >
> >
> > There may be other aspects to this issue.  But I'll leave
> > you guys with the appetizer above.
> >
> > Attached below a suggested change to [R 94] (equivalent to
> > [R 32]) on nillable rule appended with empty content treatment,
> > interpreted whereever empty content makes sense.
> >
> > Thanks.
> >
> >
> >
> >
> > Best Regards,
> > Chin Chee-Kai
> > SoftML
> > Tel: +65-6820-2979
> > Fax: +65-6743-7875
> > Email: cheekai@SoftML.Net
> > http://SoftML.Net/
> >
> >
> > ---------- Forwarded message ----------
> > Date: Thu, 17 Jul 2003 15:19:00 +0800 (SGT)
> > From: Chin Chee-Kai <cheekai@softml.net>
> > To: Dan Vint <dvint@acord.org>
> > Cc: UBL-NDR <ubl-ndrsc@lists.oasis-open.org>
> > Subject: Re: [ubl-ndrsc] Rule: 94 Nil - Duplicate
> >
> > On Tue, 15 Jul 2003, Dan Vint wrote:
> >
> > >>At 10:54 PM 7/15/2003 +0800, Chin Chee-Kai wrote:
> > >>>Amendment Required because prohibiting xsd:nil does NOT
> > >>>equate with prohibiting empty content element.
> > >>>
> > >>>Suggested change:
> > >>>
> > >>>[R 94]: The nillable attribute MUST NOT be used.
> > >>>         Empty content element MUST NOT be instantiated
> > >>>         UNLESS it is expressly a user-intended indication
> > >>>         to instantiate empty content for a given element.
> > >>
> > >>This isn't quite right. In schemas only elements of type string can be
> > >>presented as empty in a data stream without using the NIL attribute. The
> > >>user indication that nil is the appropriate interpretation is to use
>this
> > >>schema attribute (or we have to create our own method).
> >
> > It depends on what was the intention of the rule.  I took
> > Mark's response last time when he mentioned that [R 32]
> > (= [R 94]) already prohibits instantiating empty content
> > (which I didn't think that [R 32] as it stands says that)
> > to mean that [R 94]'s intent is to prohibit instantiating
> > elements with empty content.  To complete that insufficiency
> > that I though [R 94] had, I suggested the above additional
> > line, to be interpreted whenever empty content can be
> > instantiated.
> >
> >
> >
> > >>We need a statement more like this:
> > >>
> > >>Any element declared to have data, must not appear in a data stream as
>an
> > >>empty element.
> >
> > No, for such situations, during generation, it is an invalid
> > instance already.  On the receiving end, this will cause schema
> > validator to flag error based on, for example, a string pattern
> > that contains no empty string or a string restriction with
> > minLength="1" (See XML Schema Part 2 Section 4.3.2).
> > So this doesn't say more than what is already in place.
> >
> >
> > >>Elements declared as EMPTY may only appear in the data
> > >>stream as an empty element. This rule then prevents the use of the
>nillable
> > >>attribute in the schema definition and the corresponding xsi:nil
>attribute
> > >>in the date stream.
> >
> > Sorry, I lost you there;  I cannot find any term called "EMPTY"
> > in XML Schema.   Are you referring to the EMPTY in DTD terminology?
> > If so, that's outside our discussion background on using XML
> > Schema to express UBL messages.
> >
> >
> > Best Regards,
> > Chin Chee-Kai
> > SoftML
> > Tel: +65-6820-2979
> > Fax: +65-6743-7875
> > Email: cheekai@SoftML.Net
> > http://SoftML.Net/
> >
> >
> >
> >
> > >>>On Tue, 15 Jul 2003, Lisa-Aeon wrote:
> > >>>
> > >>> >>Rules for Voting:  Each email will have only one rule in it, I will
>try to
> > >>> >>mark the rules that group with it, or rules that might duplicate it.
>The
> > >>> >>membership has 5 working days to bring forth objection or
>discussion, after
> > >>> >>the 5 working days, if there are no objections, the rule will be
>assumed to
> > >>> >>be "ACCEPTED" and be given to the LCSC for their implementation.
> > >>> >>
> > >>> >>Please Reply leaving first email in Reply.
> > >>> >>
> > >>> >>Voting period on this rule ends:  July 22, 2003
> > >>> >>
> > >>> >>*******************************
> > >>> >>[R 94]  The nillable attribute MUST NOT be used
> > >>> >>
> > >>> >>Note:  Duplicate.  See Rule 32.
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >>---
> > >>> >>Outgoing mail is certified Virus Free.
> > >>> >>Checked by AVG anti-virus system (http://www.grisoft.com).
> > >>> >>Version: 6.0.498 / Virus Database: 297 - Release Date: 7/8/2003
> > >>>
> > >>
> > >>
> > >>You may leave a Technical Committee at any time by visiting
>http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php
> > >>
> > >>
> >
> >
> > You may leave a Technical Committee at any time by visiting
>http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php
> >
> >
> >
> > You may leave a Technical Committee at any time by visiting
>http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php
> >
>
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.498 / Virus Database: 297 - Release Date: 7/8/2003
>
>
>You may leave a Technical Committee at any time by visiting 
>http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]