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] Public Comment


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

>>>>>>>> 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
makeOptional()  //elementpath   Conditionally allow part of structure to be
makeMandatory() //elementpath   Conditionally make part of structure

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