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

[Art Botterell <acb@incident.com>]

Michelle -

Um, thanks for that.  [Sound of me scratching virtual diagrams on the  
inside of my skull]...

It seems like the four options you describe would have pretty much  
the same result, and mainly differ in how rigorously they decompose  
the object model.  While the object model was (maybe) useful as a way  
to discuss things, I wonder if we might be straining the not- 
unlimited object orientation of XML. ( In particular I'm not sure XML  
really has a direct equivalent to an abstract class.)

Might the simplest thing be just to define three distinct complex  
elements... e.g., <uriContentObject>, <embeddedContentObject> and  
<xmlContentObject>... and allow a choice of one of the three within  
that next-level-up container?  I'm thinking that might be the easiest  
to digest both for traditional applications and for transformation  
engines.  They don't necessarily need to know all the thinking that  
went into making it that simple.

My concern would be that about the only thing we know for sure is  
that whatever the TC chooses now, at least some part of it will need  
to be adjusted later.  With that in mind, I'd lean toward keeping the  
granularity fairly coarse and the structures fairly simple until  
we've had more opportunity to learn from experience.

But that's more an aesthetic credo than a design philosophy, so I  
defer to the assembled wisdom of the TC.

- Art


On Aug 6, 2005, at 8/6/05 10:00 PM, Michelle Raymond wrote:

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