[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 > OASIS > 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]