Re: [emergency] Groups - EDXL-DE spec discussion materials (EDXL_DE_materials.zip) uploaded

[Renato Iannella <renato@nicta.com.au>]

I am somewhat confused and a bit disappointed with the current  
discussion.

We seem to have taken some steps back with the current document (5  
Aug 05)
when we *seemed* to have reached a higher level of consensus with the  
previous document (20 Jun 05)
and now we are re-hasing some of the same issues and discussions.


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


On 7 Aug 2005, at 15:00, Michelle Raymond wrote:

> Here is the basic structure as 'DECIDED' and 'DISCUSSED' after
> Friday's meeting - at least as I best recall.
>
> The top container element <EDXLDistribution> [DECIDED] (variously
> noted as 'EDXLDist', 'distribution' and 'Distribution Message')
>   may contain two types of sub-container elements -
>     <targetArea> [DECIDED] (variously noted as 'targetArea', and  
> 'target') and
>     <messageElement> [DISCUSSED] (variously noted as 'messageElement',
> 'message' and 'contentMessage' with a leaning to rename it
> <contentMessage>).
>
> The container element <messageElement> may contain one-and-only-one
> sub-container element -
>     <contentObject>.
>
> NOTE: The content and content format of the <contentObject> is what is
> being dusted off in people's memories.
>
> Option A:  Have <messageElement> contain one-and-only-one
> <contentObject> with a choice between <contentObject>:
>      1. optionally containing the following elements:
> <contentDescription>, <mimeType>, <size>, <uri>, <derefUri> and
> <digest> or
>      2. containing valid XML not defined by the specification and with
> it's own namespace.
>
> Option B: Have <messageElement> contain one-and-only-one
> <contentObject> that contain elements: <description>, <mediaType> and
> optionally <size> and <digest> with a choice of sub-element:
>      1. <externalObject> of type URI,
>      2. <internalObject> with optional sub-element <objectLoc> of type
> URI and required sub-element <objectData> containing Base-64 encoded
> text, or
>      3. <xmlObject> containing valid XML not defined by the  
> specification.
>
> Option C: An alteration of the immediately preceding option was to
> have <messageElement> contain a choice of either:
>      1. <contentObject> with the same 'properties': <description>,
> <mediaType>, <size> and <digest> but only the two choices,
> <externalObject> or <internalObject> as sub data containers, or
>      2. valid XML not defined by the specification directly as a
> sub-element and data container.
>
> Option D: (Note: brought up at Friday's discussion.)   In
> <messageElement> add a <contentType> sub-element.  (The rest of the
> details were not ironed out.)
>
> I hope that clarifies the issue.
>
> Best regards,
>
> Michelle
>
> On 8/5/05, Art Botterell <acb@incident.com> wrote:
>
>> Patti -
>>
>> As I recall that conversation, we were trying to generalize the DE so
>> it could wrap all types of content, not just XML.  We decided that
>> there were three possible forms for a content "payload" object within
>> a DE instance:
>>
>>     1) An XML document or fragment;
>>
>>     2) A non-XML document or file included in base-64-encoded  
>> form; or,
>>
>>     3) A URI where the content might be retrieved.
>>
>> After trying several formulations, we finally settled, as I recall
>> it, on an "abstract" <contentObject> structure with three
>> instantiations for those three forms.
>>
>> If someone could relate what the proposed change was, or what aspect
>> of the prior arrangement was in question, I might be able to get more
>> specific in my recollections, although it's been awhile since I've
>> been involved in these discussions and I can't tell what I've missed.
>>
>> Thanks!
>>
>> - Art
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs  
> in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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.