[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]