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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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


Subject: Re: [emergency] Fwd: Re: IF SC Assignment Updated List




> We should be careful to note that, and note also that, as with most  
> standards in XML, there needs to be the understanding that we can  
> revisit these or any issues to change or refine them, or add  
> specific extensibility mechanisms so that we should not be caught  
> answering the question "You mean Specification X ONLY allows these  
> n types?" I could probably think up a few apparently valid message  
> types at the drop of a hat, and coming up with these "possible  
> exceptions" is something that happens just before almost every  
> final vote to move a specification to its next stage. In fact, I  
> would probably feel compelled to initiate that process myself if it  
> didn't always spontaneously generate at that stage, so please don't  
> think that I consider it a bad thing--just an inevitable and,  
> probably, a good thing in terms of applying the principle of due  
> diligence.

My point is that EDXL DE and RM are supposed to be a "family" of  
specifications.
If we know today that RM will have additional message "Types/ 
Categories" that need
to be supported in DE, then we should ensure that there is a path for  
this.
Currently, there is none, since <distributionType> is a fixed  
enumerated list.
One solution would be to remove the enumeration from the Schema and  
define the potential
values in the spec definition (and use unique identifiers for the  
values).


Cheers...  Renato Iannella
National ICT Australia (NICTA)



--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.


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