[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [cam] RE: [cam-comment] Sorry for missing the party so far
Martin, Thanks for the precision questions and edits - no issues with your list here, I've made notes below inline - and also added three more "to do" items at the end. You are rapidly expanding my 'Issues' list for the 0.13 revision of the document - and that is excellent! DW. Message text written by INTERNET:martin.me.roberts@bt.com > David, The document says "The purpose of the AssemblyStructure section is to capture the required content structure or structures that are needed for the particular business process." This leads me to think of one AssemblyStructure to one BusinessProcess. >>> Ok - need to edit that to say "particular business process step." One other comment on this is that repeating the ContentReference section on a message by message basis where the Structures used are mainly common seems to me to be a large overhead. May be this can be resolved by having the include work in ALL sections. I would be interested to understand how this ContentReference section would be used at runtime. >>> I like the idea of just the parent assembly having a single consolidated ContentReference section. Therefore ContentReference would be optional in the sub-assemblies. That will need a change to the DTD and XSD too. <<< Can you explain the CAMlevel near the front. I think the Conformance could be oved forward. The understanding of CAMLevel is important. >>> OK - agreed - I'll pick somewhere to add introduction of level approach. I think the document might benefit from be structured in to the various levels. May be? >>> Yes. I'm definately planning that - with say colour coding of the sections, or similar. I'd like to leave that for a later edit, once the content really starts to stabilize. <<< I would like to change the level for the ContentReference Section and make level 2 be able to use external non registry based XML file. I can see that Level 2 other features are worth going for without a registry. >>> Agreed - what I have now is a strawman - and I think as a group we can refine all this. I'll take a first pass and refining this in 0.13 - but everyone else shold feel free to comment / suggest here. <<< Like wise I wonder if external library functions should be Level 3 only. These are not explained in the document under this name. May be this table should refer to sections where the features are referenced. >>> OK - enhancing the table with section references is also in the game plan - if I can figure out how to make these auto-update with MS-Word - I'll do it now! >>> I made external functions Level 3 - simply because implementers will need to provide that interfacing code - and I deemed that sufficient level of effort to merit Level 3. <<< Personally I would like inline structures to be a level 1. >>> I just worry what burden that places on implementers. If we get feedback on that - then we could move it.... <<< I notice that the Syntax attibute is #IMPLIED - I suggest that defaults should be applied to all Attrubutes indicating Level 1 options, in this case default would be Xpath. >>> OK - I think we can live with that. I feel the 4.6.1 needs some work, in that the codelist could be affected by the application of context? How would this be done. Also the Lookup examples would be best to be made consistant with the ContentReference exampleso it would be possible to follow them through. Should the lookup use UID rather than name? >>> Excellent thoughts. Right now you could create a ChoiceByID() and then use the same UID by a different version - SGIR000349:01 , SGIR000349:02, etc. I think it worth creating an example to show this, and then updating the documentation accordingly. <<< Text 4.2.1 refers to example 4.2.1 showing two different structure - only one is shown. >>> Ooops! Section 4.9.1 Processor Notes. I feel that there are at least three modes for CAM processor. 1) design time gathering of document parts to build a context sensitive API. 2) Design time generation of validation scripts and schemas for the run time environment that is not CAM savvy or that does not need the context flexibilty. Think of this as a CAM compiler. This would mean that context parameters would be passed in as input to this. 3) Runtime validation engine based on context parameters and BPS definitions running within the gateways of trading partners >>> Excellent - I'll add this at appropriate point in the text. It might be worth putting this kind of spin into the Leveling piece too. >>> Agreed. I'll work this in with new text. I am sure I will have further comments, but enough for now. >>> OK! Some additional clarifications also on your early questions that I've realized apply: 1) Shared Structure concept for includes. This would allow you to create a "model" structure, then include that into various assemblies, and then tweak it with context assertions. To make this work, the structure section will need to be able to support <fragment> construct, and then be able to use an insertTree() function that takes the fragment, and the insertion point as arguments. This is a very important capability for supporting assembly of components. I will add a new section to 0.13 revision that details this capability and then we can refine it from there. 2) Scope of use of <includes> should be anywhere. This may need to be something that is granular - Level 2 feature, but again - I'll look to extend the <include> so that you can use it whereever you need. 3) Sequence of Context Rules and Precedence. We need to better explain the precedence rules on context. Basically they apply in the sequence they are written, so later context rules augment or override early rules for where the same XPaths may overlap. So XPath = //root/items/* and then followed by XPath = //root/items/size/ then that context rule will take precedence over the earlier one from the perspective of the CAM processor. This gives implementers the ability to use a lightweight mechanism that applies the logic - and requires the human to ensure that conflicting rules are applied in the right sequence. Thanks, DW.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]