[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [ubl-lcsc] Elements With Empty Content
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: > > "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 > > - 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". > > 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) > > - 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? > > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]