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] Groups - EDXL-DE spec discussion materials (EDXL_DE_materials.zip) uploaded


Art,

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


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