RE: [cam-comment] Sorry for missing the party so far

[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.

	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.

	Can you explain the CAMlevel near the front.  I think the
Conformance could be oved forward.  The understanding of CAMLevel is
important.

	I think the document might benefit from be structured in to the
various levels. May be?

	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.
	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.

	Personally I would like inline structures to be a level 1.

	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.
	
	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?

	Text 4.2.1 refers to example 4.2.1 showing two different
structure - only one is shown.
	
	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

	It might be worth putting this kind of spin into the Leveling
piece too.

	I am sure I will have further comments, but enough for now.

Martin Roberts 
xml designer, 
BTexact Technologies 
e-mail: martin.me.roberts@bt.com 
tel: +44(0) 1473 609785  clickdial
fax: +44(0) 1473 609834
pp 16 Floor 5, Orion Building, Adastral Park, Martlesham, Ipswich IP5
3RE, UK 
	BTexact Technologies is a trademark of British
Telecommunications plc 
	Registered office: 81 Newgate Street London EC1A 7AJ 
	Registered in England no. 1800000 
	This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message
in error, please notify us by telephone or email (to the numbers or
address above) immediately.



-----Original Message-----
From: David RR Webber - XML ebusiness [mailto:Gnosis_@compuserve.com] 
Sent: 12 March 2003 23:00
To: Roberts,MME,Martin,DEJC R; CAM OASIS
Cc: cam-comment@lists.oasis-open.org
Subject: RE: [cam-comment] Sorry for missing the party so far


Martin,

We do have a few gals as well (yeah I know the industry is wildly too
macho a profession!).

In answer to the question on the BP and assembly - the approach intended
is that you have separate assembly templates for each step of the BP.
That way you can more easily re-use those step centric templates across
BPs.

However - as you suggest - you could package them all together under a
'master' template - and include in the sub-assembly  for the specific
step - based on the value of a context variable.

I would say the preferred approach is separate templates.  As you note -
this then allows the BP script to reference each 
template by UID reference or URL directly.

Is there more than that - or is that sufficient here?

Thanks, DW. ======================================================
Message text written by INTERNET:martin.me.roberts@bt.com
> 
Gents, 
        I seem to have missed the subsrciption to the CAM membership and
I apologise as it was an oversight on my part.  I am intending to revise
my example of the assembly I provided before to conform to the new doc.

        However, I have a question. 

        Are you intending there to be one Assembly for a whole set of
documents that are used in a Business Process? 

        If so I think it would be good to have a formal way of linking
these in the BPSS or any other document.  For example you have used
as:choiceID against a Structure, I wonder if for that level we need to
have StractureName which could be formally mentioned in the referncing
document?

Martin Roberts
xml designer,
BTexact Technologies
e-mail: martin.me.roberts@bt.com
tel: +44(0) 1473 609785
<http://clickdial.bt.co.uk/clickdial?001609785.cld> clickdial
fax: +44(0) 1473 609834 
<