[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AM Minutes UBL NDRSC 30 April 2003
Dear all attached is a copy of this morning's minutes. The items we discussed were: 1. Containership 2. Review of ATG Guiding Principles 3. Naming rules for Business Documents. The minutes of this afternoon's discussion will be available shortly. The item under heated discussion, (the donkey is dead, long live the donkey!) was local vs global. Regards Mavis ---------------------------- AM Discussion 1. Dicscussion of containership 2. Discussion of the ATG Guiding Principles for Naming and Design Rules. 3. Naming of Business Documents 1. Containership Wednesday Morning 4/30/03 Minutes Start out with an Overview of the Containership Issue from Arofan. There are two different perspectives on this, start with Arofan. Arofan would like to see us use containers to help keep the documents more organized. Adding a Header and Body and then use the ListOf containers. Discussion Points: GS: I would like to recommend, using Header and Body, instead of LineItems. We would be having more than one body. EG: How could you have more than one body? AG: Here are the rules I am proposing: Every docment has a header. The rest of the info goes into a Body section plus Lists. EG: This doesn't seem consistent with what you had proposed before. Have the Metadata at the top within the document, then you have a body or data section. AG: I am saying that the header and the body, the body is really anything that has a cardinality of 1..n is contained within a List element, this would start with the OrderLine, for example, and that would esstentially your Body. HS: Please lets not call it Header, there are too many projects with that name and it would be confusing. EG: It is hard to generalize because you don't know what kind of documents you will be dealing with. AG: Do people worry about the numbers of levels within these containers? Should this be a consideration? EG: I think that we should be able to deal with these, that tools should be able to handle it. GS: We have 7 levels currently in the Order document. For example take PaymentMeans, you could need possibility need 4 or 10 of these. We could restrict the containership levels for some of these. We could restrict the number you need in an 0..n to maybe 10. GS: Could we add the rule, put lists only around mandatory things like 1..n not 0..n EG: The rule would be you have the container when you have more than one, not the other way around, the rule applies to the schema, not the instance. AG: PaymentMeansList that is 0..1, GS: I agree we need the containers, but I would like to show an example. 1..n and 0..n are the places we need to look at. Repeating things that are not qualified. AG: How do we come up with a rule to show that. GS: Things that are repeated a lot it will be easy to put together. AG: We have a current list of 69 items that have a 0..n cardinality, none of these seem to need a list container. Proposal: 1. All documents shall have a container for metadata and which proceeds the body of the document and is named "Head" _____________. (anything but header) 2. All elements with a cardinality of 1..n, (and lack a qualifing structure) must be contained by a list container named "(name of repeating element)List", which has a cardinality of 1..1. GS: I feel the qualifier is important, and using that as a way to tell whether or not they have or need a AG: We are going to have to explain what goes into the head at some point. EG: I don't think we need to explain that yet. Once we agree on this, then we can spend years going through that. AG: I have one last question about the naming, do we call it OrderHead or Head, I may have two things with different context within the same namespace. EG: Consenses seems to be Head, not OrderHead. Define it generically enough. Group agrees that we don't have to qualify the name? No one disagreed. Reference EMail: containership. 2. Discussion of the ATG Guiding Principles for Naming and Design Rules. Processing Instructions EG: I better make sure I am not using SOAP but PIs are always used with agreement anyway. The schemas we are constructing do not use PIs. Why would we want to tell anyone not to use them. MC: These are rules for LCSC to follow. AG: Let's say UBL will not use PIs. EG: I don't have a problem LCSC that. But what worries me is if these get interpreted by users. MC: What about Core UBL schemas will not use PIs. EG: That is fine. AG: Are we talking about schema or business instances. EG: For schemas it does not make any sense. MC: We don't want to control what people do with their instances. Mixed content LS: None of our structure uses it. EG: By agreeing to have XHTML in the documentation we have agreed to use mixed content in that area. AG: This does not refer to the documentation, it refers to the business context. EG: I disagree with you. Mixed content should not be used is what we agreed in the NDR Document v.23. Attribute Groups GS: We have not defined any yet. ID/IDREF AG: The content of business documents are referenced in other business documents using KEY/KEYREFs is different. XSD prefix AG: It must be used to refer to the XSD namespace. EG: The namespace specification is clear that you can use any namespace you want. Decisions Made: Using this document we made our own agreements at the London UBL Face to Face. ATG2 - Agreed Upon Naming and Design Rules UBL decisions marked at the end of every point. a) Processing Instructions MUST NOT be used - CORE UBL SCHEMA MUST NOT CONTAIN PROCESSING INSTRUCTIONS. b) The Nillability attribute MUST NOT be used - AGREED c) Wildcards MUST NOT be used - AGREED d) Two schemas shall be developed for each standard. One schema shall be a run-time schema devoid of documentation. One schema shall be a fully annotated schema that employs XHTML for the annotations. - AGREED e) Mixed Content MUST NOT be used - AGREED, excluding documentation. We have agreed on Should not instead of Must Not. f) Built-in Simple Types SHOULD be used where possible - NOT APPLICABLE g) Simple Type restriction MAY be used wherever possible - AGREED (LEAVE OUT "WHEREVER POSSIBLE". h) Union technique MAY be used to merge datatypes - NOT APPLICABLE, Should Not be used. (Codelists are excluded). i) Complex Types MUST be named - AGREED j) The absence of a construct or data MUST NOT carry meaning - AGREED k) Substitution groups MUST NOT be used - AGREED l) Attribute Groups MAY be used - AGREED m) ID/IDREF MUST NOT be used - AGREED n) The XSD prefix MUST be used. xmlns:xsd=http://www.w3.org/2001/xmlSchema - AGREED, The prefix "xsd" MUST be used when referring to XSD namespace. o) The XSI prefix SHALL be used where appropriate - AGREED, SEE WORDING PER N ABOVE. p) Abstract Complex Types MAY be used. - AGREED FOR UR SCHEMA. q) (not finalized) Complex Type extension SHOULD be used where appropriate - r) (not finalized) The 'final' attribute shall be used to control s) (not finalized) The 'block' attribute shall be used to control t) Complex Type restriction SHOULD be used u) The 'final' attribute SHALL be used to control v) The 'block' attribute SHALL be used to control w) Key/KeyRef May be used - AGREED, not finalised for our purposes. We still need to work through and define rules. x) Notations MUST NOT be used - AGREED y) UpperCamelCase (UCC) MUST be used for naming elements and types - AGREED z) lowerCamelCase(lCC) MUST be used for naming attributes - AGREED 3. Naming of Business Documents - Discussion lead by Gunther. We have alot of different ways of naming business documents. What kind of terms must be placed in those names. Consitent naming is needed for exchanging of documents between trading partners. We need 3 terms. Rosetta Net use 3 terms for the definition of the business documents. MC: The way we name our documents is dependent on our decision on versioning namespaces? AG: It should not be. MC: If we don't version our namespaces then we have to version our document namespace. MC: Should we also version our document namespace. EG: There is a proposal that chairs of Oasis Committees prepared for filenaming in Oasis. MC: Do we need to look at that? EG: Probably. It is a fairly reasonable. MHC: Let's look at that. SP: This came up in LCSC as a question too. GS: Should we use the tripartite structure, substantives, verbs and in which order. SP: There is a UN codelist that gives us a list of document types that we would like to be able to link to. EG: Let's look at "Proposed Rules for OASIS document File Naming" by Oasis Working Draft 02, 18 February 2003. SP: Some of the aspects of these will be applicable but the semantics of the names is another aspect as well. EG: There are some some general principles which we don't have a problem with.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]