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

David -

The schema language you suggest sounds like it could be useful, at  
least in the <xmlContentObject> case.

Might we want to apply the processContents="lax" argument more  
globally to ward off unnecessary validation errors?

- Art

On Aug 7, 2005, at 8/7/05 9:20 AM, Ellis, David wrote:

> Art and TC
> The <contentObject> element or any of the elements you propose below
> need to have an attribute which defines a schema for the arbitrary
> elements which are used in the <contentObject> container element.
> Also, the <messageElement> is the container element for the
> <contentObject> and all metadata pulled from the <contentObject>  
> should
> be from the same schema.  By using the "##other" namespace  
> definition in
> the <messageElement>  all contained XML content can reference the
> redefined namespace by using the "##targetNamespace" attribute.
> <element name="messageElement" xmlns:me="##other">
> This allows the XML pulled from the <contentObject> to be used in the
> <keyXmlContent> .
> <element name="keyXmlContent" minOccurs="0">
>     <complexType>
>         <sequence>
>             <any namespace="##targetNamespace"
> processContents="lax" minOccurs="0" maxOccurs="unbounded" />
>         </sequence>
>     </complexType>
> </element>
> By using the "lax" processContents validation option if the schema is
> not available the parser will ensure the labeled elements are well
> formed and continue to process the XML.
> Therefore any arbitrary XML structure can be used and validated by the
> Parser (SAX, DOM etc.).  Because the schema defines the structure and
> value type for the contained elements, it is this schema and not the
> container element name which the parser must use for determining  
> how to
> process the content.  If we force developers to interpret an element
> from a choice and then parse and process this data in some special  
> way,
> I do not understand the benefit of this increased complexity and I am
> sure it will break receiving applications processing which  
> implement it
> differently.
> <element name="contentObject">
>     <complexType>
>         <sequence>
>             <any namespace="##targetNamespace"
> processContents ="lax" maxOccurs="unbounded" />
>         </sequence>
>     </complexType>
> </element>
> I have very strong experience to support my reasoning and this is
> similar to the method the SOAP schema allows for inserting  
> arbitrary XML
> content and still uses schema validation.  Please provide me your
> proposed schema for validating the elements you are proposing.  I am
> trying to complete the schema for the distribution element and need  
> your
> schema and subsequent XML documents to run thru validation tools.  We
> are tying to get the EDXL Distribution element out for public comment
> and need this soonest.
> David E. Ellis
> Information Management Architect
> (505) 844-6697
> -----Original Message-----
> From: Art Botterell [mailto:acb@incident.com]
> Sent: Sunday, August 07, 2005 12:14 AM
> To: Emergency_Mgt_TC TC
> Subject: Re: [emergency] Groups - EDXL-DE spec discussion materials (
> EDXL_DE_materials.zip) uploaded
> 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
> ---------------------------------------------------------------------
> 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
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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