OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cam-comment message

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


Subject: 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]