[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]