[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency-if] Excerpts from Issues for EDXL-DE we need to add to issues list for 2.0
Dave - Thanks for this compilation. Very useful. On one point: Art agreed to be the coordination point for the ITU-T, Tom and Dave will continue with the sensor work in the IF-SC and represent the TC at the NIST and other sensor standard discussions. I hope that this activity remains coordinated with the OGC and ISO. There are numerous sensor web/network activities being rapidly progressed in both the OGC and ISO, including a JTC-1 activity. I would also encourage the EM TC to take a look at the Sensor Fusion RFI that the OGC recently released. http://portal.opengeospatial.org/files/?artifact_id=38987 Regards Carl > Don > > Here are some issues I have gleaned from the past. I was not the issues > list keeper and there have been many things deferred but may now be lost. > I > believe Rex is going to send you a current example of how to maintain an > issues list. > > Dave > > 1. EDXL-DE Update > > Tim has agreed with the resolution that EDXL-DE can have multiple > contentObjects with one and only one payload each, and one and only one > DistributionType, so that no contentObjects could be of a type different > than the DistributionType. Patti has incorporated this into the latest > version of the draft. This was the only remaining issue on the EDXL-DE > draft. > ____________________________________________________________________________ > _________________________________________________________________ > a. Dave said there was a deadline of 8 January to respond to ITU. > Elysa stated that we certainly want to respond to each of the 3 issues > that > have been discussed; we have no requirement to respond to ITU by that > date. > As Jamie instructed us, the OASIS staff has the responsibility to address > the ITU. We will put these topics on the agenda for discussion but > discussion could also begin now on the list. Dave is most concerned about > points that effect the DE and will get with Rex on the issues. Elysa > added > that all three points will require special discussion and may need > separate > meetings to address them > > ____________________________________________________________________________ > ___________________________________________________________________________ > Dave Ellis has identified some possible issues with various applications > using FIPS 5, FIPS 6 and UNLoCode. Dave is continuing to research the > issue > and will have a more formal listing for the issues raised. > ____________________________________________________________________________ > __________________________________________________________________________ > 2. EDXL-DE > a. Remaining Issues > The remaining issue with the DE is with regard to > the <any> element. There was much discussion on the call about this > relative to Dr. Iannellas comments on the list. A variety of opinions > were > discussed. Signatures for target area and differed for a future > resolution. > It was agreed that we would add a clarifying comment to the data > dictionary > as follows. We realize this is possibly not optimal but can be revisited > at > the next revision. > b. Changes since 60 day public review are being summarized by Patti. > c. Path Forward > Dave Ellis pointed out again how important it was to > get the DE through as soon as possible. They are using it in the Alerting > Framework and must move ahead. We discussed the fact that the changes > made > to the DE since the 60 day comment period were minor in nature. Since > there > are changes, the document must go back out for a 15 day public review. > The > reviewers will only be able to comment on the items that have changed. > Patti will make the changes per our call today and post it to the site. > All > agreed to review the document and schema to make sure all comments are > appropriately addressed. We will have a meeting January 17 at 12:00 EST. > A > vote will be taken to submit this draft for a 15 day review. This vote > will > require a full majority vote. An electronic ballot is not necessary. > Once > we have done this, Mary will post the documents on the OASIS site (either > 1/17 or 1/18). The 15 day review will run through Feb 2 or 3. We will be > able to address any comments raised during that period until Feb 6. We > will > call a special meeting if necessary to address any comments. We will have > a > regularly scheduled meeting on 2/7. At that time we will vote to 1) to > approve this document as a Committee Specification and 2) to take this > Specification to OASIS for a vote to ratify as a Standard. It will be > submitted to the OASIS wide community on the 15th. The actual OASIS wide > ballot will run from March 16-31. > > 3. Consideration of Dr. Iannella's proposal for the EDXL DE model > > The group noted Dr. Iannella's formal objection to > consideration of the current EDXL DE draft as a proposed committee draft. > Elysa recognized the amount of thought and effort Dr. Iannella put into > his > proposed model, and apologized to him in absentia for not acknowledging it > earlier. > > She then asked the group if they had fully considered the > model proposed by Renato. Several members (specifically Rex, Tom, Gary, > David, Michelle and Sylvia) expressed that they reviewed the comments and > felt like each had been addressed. Rex said that Renato's model had not > been ignored, but that he himself had referenced it during the initial > discussions and had adopted many of its ideas during the interim phase, > and > that it had proven very helpful. However, the DOM model seemed to be the > consensus of the group. Gary said that he liked the information model very > well from a design standpoint, but that as work progressed they had > decided > that creating a more meaningful organizational model would require a > different structure. The current proposal combines ideas from Renato's > model > with other members' ideas, as well as the concepts formulated at the New > Orleans meeting. Art expressed concern that a model that was originally > provided as a suggestion to the committee is now being framed as an > alternative. It was also noted that Dr. Iannella's model was never adopted > by the committee. > > The committee then considered whether it would be useful to > have an information model in addition to the DOM. Carl brought this up and > informed us that both a logic and data model are represented in the OGC > specifications. Rex felt that it might be confusing to add the > information > model, and would cause a delay in release of the proposal. Patti suggested > including the information model in the "cookbook" implementation guide > she's > working on. The group agreed that the current DOM would be the only model > in the specification. > > 4. Outstanding EDXL DE issues > > We discussed how we are going to manage the issues and > versions in this fast-paced week of trying to finish up this Committee > Draft. Michelle started an issues list via the list. These with their > status are contained in subsequent paragraphs. We are asking anyone at > this > point when an issue is raised to please also offer a proposed solution for > discussion and any ramifications they envision. The document in its > current > form will be numbered EDXL/DE 0.1. Each time we make changes, this number > will increment until we get to the 1.0 committee draft. > > Michelle led the discussion on outstanding EDXL DE issues. > She asked for volunteers to maintain a more formal list of issues, and Art > volunteered to do so taking the initial feed from Michelle's' handoff > today. > He strongly encouraged anyone submitting an issue to include with it an > affirmative suggestion. > > David agreed to write up the issue of value list and value > pairs being able to appear multiple times, and to provide his suggested > implementation. > > Michelle is going to write up, for further discussion, the > choice among URI, derefURI, and XML namespace. > > There was discussion of the appropriate name for the > location element. Everyone liked the idea of including UN in a way that > wouldn't be confusing. Art suggested using locCodeUN, and the group > agreed. > > Sukumar noted that the current draft could use more of a > history, which David and Tom are working on. Elysa offered to help with > that > effort. To offer an example usage scenario, Sukumar will provide the > prototype he used for his earlier demonstration to Michelle by Thursday. > > Julia will get the identifier number and other designators > required by OASIS from Mary. > > The following details were submitted by Michelle to the list > but are put here as well. All of the "PROCESS", "ISSUE" and "EDIT TASK" > items were noted in the meeting except the third PROCESS note. That is > Michelle's suggestion as to how to facilitate communication. It might also > be good if we also prefaced the subjects of our emails as "EDXL_DE_ISSUE, > for example. > > 5. EM data exchange initiatives > > The group discussed changes in U.S. agencies and warning > initiatives that may impact the committee's work. Dave updated the group > on > NorthCom, which has been given the lead in meetings to take place in early > January, and which he will be assisting. DMIS is now capable of handling > EDXL content, but is not able to store data having to do with pre-event > detection or tracking of individuals. The Domestic Nuclear Detection > Office > (DNDO) is doing a joint pilot with the Department of Justice. Tom and Dave > are going to be leading the sensor architecture effort. Infrastructure was > going to look at existing sensor systems, and whether they would > recommend > to the committee that they work on a new sensor schema. DNDO has expressed > interest in using the ANSI 4242 standard as content for an EDXL message. > Tom > is waiting to hear back from Michelle on her sensor standards survey. > > Liaison Assignments: Art agreed to be the coordination > point for the ITU-T, Tom and Dave will continue with the sensor work in > the > IF-SC and represent the TC at the NIST and other sensor standard > discussions. Patti agreed to represent the TC to the HS Standards group > she > has just joined. Elysa is to have a telecon with Jamie and Mary of OASIS > about liaison relationships. DNDO specifically asked Elysa to look into > how > they would become members of OASIS and in what capacity they should/could > serve. They also asked about how MOA and other type of relationships > existed between OASIS and other standards bodies, specifically ANSI and > OGC. > > > A persistent issue has been the ability to test prototype > standards. Dave currently doesn't have anyone test the DE with, but should > be able to do so with the MyState site soon. Next would be CIST, in order > to > test security, including SSL. After that, the committee should consider > interface standards to commercial systems. > > > 6. EDXL-DE Progress > > The current plan is to put the draft revision out for > comment on January 7th. The key change is that the ANY element has been > put > back in. With the addition of the choice statement, signatures will no > longer automatically work. The ANY element will be required at the end of > a > sequence in order to sign a content object. > > There was discussion of whether it was possible to put a > namespace in an element without first declaring it. If not, that will > require another change in order to have an ANY element and an ANY > attribute. > This should be checked by others with validation tools. If it doesn't > work, > that will require a second change to the draft. > > Art Botterell has proposed a change in methodology for the > future, which is to create the data dictionary first, validate it, and > explain what each element is intended to accomplish. After this is > complete, > the schema could be created. Dave proposed instead doing both at the same > time. Since Art's proposal had to do with methodology rather than results, > Renato's issue is the only one remaining. Patti is going to finalize the > draft and get it out on the list so that Renato can comment if he wishes. > She will change both the document and the XSD so they will match. > > Once the new draft is OK'd, the 15-day review period can > begin. That would allow the ballot to go out for review to the general > membership by the end of the month, and for general voting to begin on > February 1. > > Gary has published a prototype of the DE, but not many > people have used it. He may try to get data from Dave to post internally. > He > asked whether the committee should start working on a "cookbook." Art > suggested publishing sample code for the transport layer. There was > discussion about implementation issues and whether WSDL should be the > focus, > as well as whether Java provides the most transportable architecture. > Elysa > said it has reached to the point where someone needs to put sample code > out > on a cookbook. Dave questioned whether that would be possible given that > many of the examples will require sensitivity to security issues. Elysa > emphasized that no secure data should be in the cookbook. Art noted that > even "pretend" sensitive data can be complicated, since there isn't a > security version of "lorem ipsum" yet. > > The remaining to-do item is to check with Mary McRae to make > sure assumptions about the schedule are accurate. > ____________________________________________________________________________ > ____________________________________________________________________--- > Distribution Type issues > . Mandatory "enumerations" which are not complete and are causing > adoption and semantic ambiguity issues especially in compound messages or > workflows. > . Must determine use within EDXL distribution system > - Why have this tag anyway? (framework versus edge system) > . Composition of "distributionType" (URI and/or XRI) > - Registered EDXL Distribution Systems > - Distribution System COI label > - Content Objects Schema / Context > - Schema/Context Distribution Type > . Provide guidance for "distributionType" creation and mapping between > EDXL Distribution Systems (must be unique) > ____________________________________________________________________________ > ____________- > Security Labeling Issues: > Controlled Unclassified Information and specific metadata from Federal > agencies needs to be discussed for ContentObjectZero > ____________________________________________________________________________ > ________________ > PROCESS: The documents would be clearer to differentiate as separate > entries into KAVI. > > Suggestion: Name the documents by version numbers, "0.1", "0.2" ... > > Proposal: Put the file of the draft specification in KAVI as > "EDXL_DE_Draft_V0.1.html" and add files as they are incremented rather > than adding a revision to the existing KAVI entry. > > Action: Michelle will check in the first of these drafts and update > them after each meeting this week with a new entry and version number. > > > PROCESS: We need an official keeper of the issues. > > Suggestion: Rope in a volunteer to maintain a table of issues. > > Stuckee: Art (with backup support from those who volunteered on the call) > > > PROCESS: We need to keep the types of material flowing through email > and other forms of converse clear. > > Suggestion: Going forward, for ease of differentiation, in > communications please note what is a content issue as "ISSUE:" , what > is a document spiffing up or formatting goof as an "EDIT TASK:" and > what is a point-of-proceess as "PROCESS". > > > ISSUE: Use of multiple <value> elements in conjunction with a > <valueListUrn> element, where the values are from the value list, > should be supported. > > Originator: Dave Ellis > > Rational: This reduces the reuse of the container elements (<keyword>, > <senderRole, <contentKeyword>, etc...) and the need to repeat the list > name in each of these container copies. > > Example: > <consumerRole> > <valueListUrn>railway:sensor:hazamat:alertRecipien<valueListUrn> > <value>hazmat.northLine@goRail.com</value> > <value>application/CAMEO/plumeReport.bat</value> > <value>fireDepartment@centerCity.gov</value> > </consumerRole> > > Suggestion: Allow multiple <value> elements with an associated > <valueListUrn>. > > Proposal: Within the "container" elements (<keyword>, <senderRole, > <contentKeyword>, etc...) require one-and-only-one <valueListUrn> > element and one-or-more <value> elements. Also, make certain it is > documented that each of the container elements could be used > more-than-once. > > Action: Proposal accepted. Changes to be made in the schema and > specification by Michelle. > > > ISSUE: Add a <location> element to the <contentElement>. > > Originator: Dave Ellis > > Action: Dave to write up rational and proposal. > > > > ISSUE: A <choice> between <uri>, <derefUri> and > <namespacedXMLContent> should not be forced in a <contentObject> > element. > > Originator: Michelle Raymond > > Reasons: 1. The <uri> element may be desired in the same > <contentObject> as one containing a <derefUri> element to direct to > where the dereferenced document is held. > 2. The <uri> element may also be desired in the same > <contentObject> as one containing a <namespacedXMLContent> element to > direct to where the XML document is held. > > Suggestion: Take out the <choice> element and set each of the three > elements to attributes of minOccur="0" and maxOccur="1 > . > Side-effect: This does allow for a <contentObject> to not have any of > the three element types as sub-elements. These seems ok, as sometimes > the synopsis is all that needs to be communicated. > > Proposal: Several were mentioned (see action.) > > Action: Michelle to write up the potential proposals discussed. > > > ISSUE: The name for the UN/LOCCODE, <location> in the <targetArea> > element is too generic. > > Originator: Michelle Raymond > > Reason: "location" has too broad of a potential meaning. > > Suggestion: Rename <location> to <locCode>. > > Proposal: Rename <location> to <locCodeUN>. > > Action: Proposal accepted. Changes to be made in the schema and > specification by Michelle. > > > ISSUE: <originatorRole> and <consumerRole> provide less confusion > against <senderRole> and <recipientRole> but do not disambiguate > clearly. > > Originator: Michelle Raymond > > Reason: ambiguity as to context is not available from the naming. > > Suggestions: Option 1: use <senderRole> and <recipientRole> in > <EDXLDistribution> and use <messageOriginatorRole> and > <messageConsumerRole> in <messageObject>. > > Option 2: use <distributionSenderRole> and > <distributionRecipientRole> in <EDXLDistribtion> and use > <contentOriginatorRole> and <contentConsumerRole> in <contentObject>. > > Proposal: Leave as is. > > Action: Leave as is. > > > > EDIT TASK 00: Review draft of Specification > Stuckee: EVERYONE - provide issues with reasons and suggestions > Stuckee: EVERYONE - note consistency issues in text, typos, formatting > problems, quibbles and nits about document structure, etc. > > EDIT TASK 01: Get the [Document Identifier as per OASIS Artifact > Naming Guidelines] > Stuckee: Julia (Thu.) > > EDIT TASK 02: Get the [OASIS Document Number] > Stuckee: Julia (Thu.) > > EDIT TASK 03: Add links to Chair and Editor company names > Stuckee: Michelle (Thu.) > > EDIT TASK 04: Add [Comma-separated keyword listing] > Stuckee: Sukamar (Thu.) > > EDIT TASK 05: Determine the OASIS Conceptual Topic Model Area - [Please > refer to (link) for appropriate topic area]] > Stuckee: Julia (Thu.) > > EDIT TASK 06: Put in reference to CAP 1.1 for related spec. > Discussion: This should be 'related' as in an example of how the > <namespacedXMLContent> may be used. > > EDIT TASK 07: Add more History. > Stuckee: Tom (Thu.) > > EDIT TASK 08: Add or delete Example Usage Scenario > Stuckee: Sukamar (Thu.) > > EDIT TASK 09: Check for consistent bolding and bracketing > > > 7. EDXL timetable > > To fulfill its goal of having a committee draft ready for > vote by the end of the week, the group agreed to meet on both Wednesday > 3:30 > EDT and Thursday 9:00 EDT to continue the discussion. > > > > Respectfully submitted, > > Julia Ridgely, Secretary > OASIS EM-TC > President > Long Branch Systems > (443) 604-8699 > 1. Outstanding EDXL DE issues > > Discussion resumed of the remaining EDXL-DE open issues as > posted by Art on the site in the 8/18/05 issues list. > > Michelle thanked everyone who sent comments and > contributions to the draft, and said there were three remaining issues to > be > considered. > > The first was issue 9, the proposal not to encode payloads > that can be delivered by other means. This issue concerns the size of the > DE > in some implementations where there is limited processing capability and > bandwidth at the point where the DE must be processed. The size issue > mainly concerns the <nonXMLContent> and the <derefUri>. Discussion on the > topic continued for some time. Unfortunately, Kon who raised the issue > could not be on the call. We discussed the size of the DE and the fact > that > the way it is currently specified, the DE could be very large and could > actually have an undetermined size since it could contain live video in > the > <nonXMLContent>, as a worst case example. Where most senders will be able > to calculate the size and store it in the DE, in some cases, the sender > will > not be able to determine this size. David very much needs the ability to > have a DE that can have a large <derefURI>. We discussed how to > accommodate > both high- and low-bandwidth users. Rex offered a motion to document this > as > an open issue in the draft but withdrew it after further discussion. Art > moved and David seconded a motion to note this as an implementation issue > that is out of scope for the specification. All agreed. > > As an aside, David said he had not been able to get > clearance for the example he offered, so it will be omitted not only from > the draft but from the implementation guide and wiki for now. > > In consideration of the issue of low-bandwidth users, Gary > made a motion that was seconded by Rex to make the <size> be mandatory > whenever <derefURI> is used. This will allow systems the ability to know > the > size prior to ingesting the entire message. It was discussed that this > will > only help where the parser does not require the entire message to be > ingested at once. There was also discussion about whether it would make > sense to have <size> be mandatory for URI as well but decided against. We > also discussed whether <size> should be able to be indeterminate, e.g., > streaming video. We decided not to do so at this point since streaming > data > is a different situation and should be considered separately when raised. > The motion passed unanimously. > > The second issue, issue 10 on the list was raised by Renato > to rename <derefURI> to <contentData>. We agreed this is a more fitting > name, however the EDXL-DE will be inconsistent with CAP 1.1 on this point. > We agreed that when we align these standards at CAP 2.0, we can make the > change in CAP from <derefURI> to <contentData> at that time. A motion was > made by Michelle and seconded by Art to make this change in the DE. The > motion passed unanimously. Michelle will take care to make sure all > appropriate references in the document are changed. > > Issue 11, a proposal by Renato to change <valueListURN> to > <valueScheme>, was discussed. The impression of the group was that this > issue was cleaned up with the resolution of Issue 8 to disambiguate > <explicitAddress>. We discussed the proposal and looked at re-opening > issue > 8. We agreed that was not necessary. A motion was made by Art and > seconded > by Michelle to respectfully decline the suggestion to rename > <valueListURN>. > All were in favor. > > All issues had been addressed and we began to do a final > review of the remainder of the specification. Each section of the draft > was > reviewed by the group with Michelle leading the discussion. Several > editorial corrections were made. > > Art reviewed comments he has received from the public on the > Distribution Element. They include making digital signatures mandatory, a > tag for language used, and a question about whether there should be > multiple > XML or non-XML elements. The National Wildfire Coordinating Group > requested > an incident identifier and description. Art will be preparing and > circulating a list of all comments and issues. > ____________________________________________________________________________ > ______________________________________________________________________ > Open Issues > > 1. General Requirement "Incident and Event Reference". > > In the EDXL Distribution Element, this is handled using a "keyword" > element > providing the capability to link to any value from a discrete managed > list. > This could be used to specify an incident or an event using the Uniform > Resource Name (URN) of a published list of values and definitions. This > approach was pursued in an attempt to make the standard more flexible. > > ISSUE: This approach makes the assumption that each resource message - > even > a resource message containing multiple payloads - will be referencing the > same incident or event. This assumption must be tested and validated. > > This issue will be addressed during the OASIS technical committee review > process, with input and feedback provided by the Standard Working Group > through EDXL project team OASIS members. > > ____________________________________________________________________________ > ________________________________________________________________________ > > These are issues from the Face to Face: > > > Review issues identified during Sept F2F to be addressed in DE follow-on. > Dave Ellis to provide brief context for the current unmet needs in the DE: > > 1. Acknowledgement (reply to/error to) (Optional, could be 1.1) > Does the message reach the end user? > Define where the grid starts/ends - given distribution technology > Requirement: The DE shall provide the sender with feedback to confirm > transmission of message to the redistribution system(s). > Note: The DE should support load balancing in methods of redistribution, > but it is understood that this is not a requirement of the DE > What is in the 1.1 draft should be reviewed (string or valuelistURN or > value > scheme) > Responsible - Included in draft now as string, need to change to structure > of explicit address. Hans > > 2. Hop count - sounds like a system requirement, not a DE requirement > (router specific - Hans/Jeff/Don) > > 3. Distribution type - mixed mode, content objects with different > distribution types. Note - dependency on current approved standards > RM/HAVE. > Needs to be "fixed" in next revision. Fix or do differently. > Maybe recommend one distribution type per message, need to determine > whether > the structure needs to be single distribution type or single content with > multiple distribution types. (2.0) Suggest valuelistURN so that other > standards (RM/HAVE doesn't have to change). Possibly need to add t. > Topic > for discussion during IF-SC meeting. Discussion about adding tags for the > routing params (update/cancel..) Those having specific interest/knowledge > (Gary/Tim/Rex/Michelle - need diversity and history) > FORWARD SHALL BE A TYPE - with example and explanation (base64 encode full > message, security ramifications, tracking/logging) > > 4. Re-evaluate header vs content (2.0) > What must be fixed is putting info about the content in the header. What > is > used for policy decisions and where it goes - distribution vs > contentObject. > If it has to do with routing whole message - Distribution. If it has to > do > with routing a piece of content based on specific purposes, it would be in > the contentObject. This will be worked in IF-SC meetings - those having > particular interest/knowledge - Michelle/Rex/Gary/ - > > 5. Conformance section - Dave - five levels of routing, > policy/distribution > should include conformance for the routing points. > There is a need for different levels of conformance. > DE conformance section must be added, it will have to grown. > Gary - be careful of over specifying it. > NIMS-STEP folks have offered to provide input > > 6. Policy methods for routing - emergency message routing > What are the unique needs of the routing element for emergency needs. > Where does routing detail go? Determined that there must be a Routing > Specification (Jeff/Hans/Don/Michelle - others as needed) > 1. Capture detail experience about routing (Jeff/Hans/Don working with > Dave) > 2. Create bullet points of what a basic routing capability should be > for within the DE spec. A full blown spec will likely follow.. (Rob) > 3. Routing spec for EM will follow and have its own conformance spec. > (levels vs capabilities - 5 discussed in the early days, Gary added that > this should be capabilities) > > 7. Name space for DE - Name space restriction on content object > NO DE wrapped in a DE - don't layer Des, specifically for security reasons > Consensus - we will not do this. (see forward reference in distribution > type) > > 8. URI instead of URN > URN - allows global unique id, doesn't require going to the web for > reference (URNs are controlled - Rex) > URNs are not affective for small county jurisdictions (Don) > High speed routing - URN and locally specified lists can use URI (Gary). > DM-OPEN is taking code lists from NIEM code lists - that can be locally > available > URL in current spec mistake, > Don- should be able to use URLs > Question - should the valuelist URN/URI/URL/Code list all be allowed. > Dave will try to provide detail need for URN exclusive - for high level > systems > Specific changes to spec - changes from spring to any URI and change the > name to valuelistURI (Jeff/Don/Rex/Hans - > > 9. Non-XML Content - add new element for digest type and update digest to > remove SHA-1 (refCOID and COID) - both XML and non-XML content. Structure > (not a string). Examples need to be included in spec for clarification. > Doug - examples/Hans - update 1.1 tech (CSV), use case (multiple content > object) > > 10. Area - readdress with next revision, See EM Routing concepts Version > 4, Michelle - support multi area geometries, include GML Where, Hans - > order > of preference for areas. Michelle - add tagging of level of detail, Doug > - > need FIPS (SGC). Request GIS-SC to weigh in and provide guidance > Particular > interest Carl/Rex/Michelle/Doug/Hans/Rob > > 11. Confidentiality and Combined confidentiality - Enumerated list? URN? > This topic must be covered in the next revision. Keep required but make > it a choice - between a string and valuelistURN. Can't be ignored. Rob > > 12. xmlContent - OOPS - need to change the name because it is not a > valid XML tag name. Needs to be fixed. "ContentXML" - Hans > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to 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]