[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: re: [cam-comment] Public Comment
Kit, Thanks for taking the time to do these for us. I think we have the points mostly covered - and clearly we need to make the document better - to make this obvious to readers - and as ever your sharp eye caught these. I've included responses to your points - and in due course we will have an official responses spreadsheet posted. In the meantime - these are the quick answers! Thanks, DW. ==================================================== Comment from: kit@mitre.org CAM Specification v1.0 Committee Draft. Review comments by Kit Lueder, The MITRE Corp. Phone 703-883-5205. Thank you. 4.2 Assembly Structures: It should be able to reference the XML assemblyStructure as an external file, rather than having to include it in-line in this same file. This can be a maintenance nightmare, otherwise. Suppose you have a hundred trading partners (TP), and you provide one of these CAM structures for each TP. If you have to include the XML assemblyStructure in-line in each of these hundred files, it is difficult to maintain as the structure evolves; it is easy to maintain if they all reference the same external file. >>>>>>>> REPLY : Actually CAM does indeed have <as:include>URL</as:include> and as:include="URL" directives. There are examples of a multi-file include - in the "Advanced Usage" section. However - we need to make mention of that here - so people know that option exists when reading at this point. <<<<<<<< It should be able to reference an XML Schema now, using the external file reference capability I cite above. A minimal capability would be to reference a file path for where the XML Schema file is. >>>>>>> REPLY: Agreed. And I recently did an example of exactly this - building a complete XSD schema from selected fragments of XSD syntax as includes. <<<<<<< Section 4.3, Figure 4.3.3: Why does it distinguish between an attribute and an element? Why not have one mechanism, and if the xpath parameter refers to an attribute, it is an attribute that is excluded?: excludeAttribute () //elementpath@attributenameConditionally exclude attribute from structure excludeElement() //elementpath Conditionally exclude element from structure >>>>>>>> REPLY: This is mostly a hint mechanism to the CAM processor - to know its dealing with one reference type or another, and having both allows better validation of the exclude...(XPath) statements themselves - as clearly an attribute reference in element is an error, etc. We could have had excludeItem() - but on field tests - people were confused - and needed the excludeElement / Attribute as they are familiar with those constructs. <<<<<<<< It should clarify if makeOptional() and makeMandatory() apply to attributes as well as to elements. If so, why does one function apply to both element and attribute, while "exclude" does not? If not, how do you make an attribute optional vs mandatory?: makeOptional() //elementpath Conditionally allow part of structure to be optional makeMandatory() //elementpath Conditionally make part of structure required >>>>>>>>> REPLY: Agreed - this is not consistent - you are correct the makeOptional / Mandatory DO work with attributes as well. This should be made explicit in the documentation at this point. <<<<<<<<< Taxonomy is defined as follows. I suggest that one CAM file should be able to reference another CAM file, to apply additional constraints. Thus, "CAM" should be another possible value for taxonomy attribute.: taxonomy (XSD | DTD | RNG | XML | EDI | HTML | MERGE | OTHER) #REQUIRED > >>>>>>>>>>> REPLY: The import and include mechanisms are intended to allow CAM within CAM. This gets somewhat more complex - so we are planning to enhance this in V2.0 - defining precedence rules for includes, and just having simple mechanism for CAM within CAM for V1.0 <<<<<<<<<<< Rather than just "EDI" in "taxonomy", it should differentiate between "X12", "EDIFACT", and "HL7". >>>>>>>>>>> REPLY: The intention is that EDI is infact X12 - and that as more interface specifications are added - this list will be extended. For V1.0 we anticipate EDI-X12 is the most likely needed. <<<<<<<<<<<
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]