XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] What does "optional" mean?

Roger--

The sorts of schemas you seem to be talking about are describing data formats, not semantics.  In a data format (a database structure, a file structure, an XML document), you make something mandatory because it has to be there in order for the applications using that data format to work.  Its part of the mutual agreement that everyone involved has presumably made.  Based on that, you reject input data that doesn't provide the mandatory stuff, because the consumers won't be able to use it (or it's not worth trying to use it, or some arbitrary authority has decided they won't accept it, but never mind).  That's it.  And it's not specific attributes or elements *by themselves* that are either mandatory or optional, it's *in the context of that data structure* that they are mandatory or optional.  The IRS has decided that a TIN (or SSN) is mandatory on various forms used in dealing with them.  That doesn't say an SSN is "highly important" in the abstract;  it says it's highly important in the context of their being able to process the data on this form.  Admittedly, many organizations seem to ask for more information on a mandatory basis that seems strictly necessary to process whatever transaction is being conducted, but nevertheless the basic issue here seems to be will applications using this data structure not be able to work properly unless certain information is there.     

Other information is optional, because the using applications (or hopefully at least one of them) can make use of the information if it's provided, but it need not be provided, either because it doesn't apply to all providers, or you may not want to force them to provide it, or some other reason.  Now conceptually you could imagine specializing data formats to the point that all information in a given data format was mandatory (each distinct data format corresponded to a particular processing case that accepted only the data it required, and required all the data it accepted).  Some of Hugh Darwen's work that Jim Melton mentioned involved this basic idea;  that you could "kind of normalize" database structures to the point where no nulls were needed.  But that made query processing on those databases really messy, due to the number of specialized relations that were defined.  

BTW, as further illustration that data elements shouldn't be considered mandatory or optional independently of context, consider a person's name (or other personal identifying information).  That can be mandatory in some circumstances, optional in others, and absolutely prohibited in still others (for patients in certain medical records).  This latter isn't an issue with structured data formats, since "prohibited" can be handled by "don't provide a place for it), but hopefully you get the idea.

--Frank


On Feb 26, 2012, at 11:16 AM, Costello, Roger L. wrote:

>> I would agree with David Carlisle.
>> In schema,  "optional" doesn't mean ANY of the items you suggest.
> 
> Yes, I stand corrected. Despite my best efforts, how quickly and easily I fall into the trap of ascribing meaning to constructs in schemas.
> 
> Let me rephrase my question: 
> 
>       Why make one element mandatory 
>      and another optional?
> 
> That is, what is it about some information that it is declared mandatory whereas another information is declared optional?
> 
> /Roger
> 



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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS