[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: UBL NDR SC Minutes London F2F May 2003
Dear all please find attached the complete set of Minutes from the NDR Face to Face April 28-May 2nd 2003. Regards Mavis
Naming of business documents Part 2 - led by Gunther Stuhec Reference Material - draft-stuhec-NameTrun-01.doc GS: One of the most important things is performance. Transformation slows down performance. For high reusability i.e. you can always use all the tag names in different applications and development environments (UML class diagrams, storage Databases, interfaces) not just for XML schema or XSLT exclusively. This will help SMEs to use our business documents. There are 2 problems if the the tag names are too long 1. You cannot use long names within all applications or interfaces. These are often restricted. For example, SYbase restricts to 32 characters for a name, MS Access restrictes to 150 characters, XML Spy restricts to 50 characters, SAP application interface restricts to 100 characters. 2. Transformation of tag names between the internal system and the instance. If you put the XML instance in to your internal workflow you need transformation. If the tag name is long, the transformation will take time not rendering the system very performant. XML says the tag names should be human readable which is good for the modelling of interfaces. I propose the longest tag name should not be longer than 32 characters, therefore most applications can use these. We need to think about how to truncate these tag names. For global elements we can truncate the object class term possibly. We should also use more common abbreviations and not just ID, DUNS etc. See Section 4.1 of the paper for details on this. EG: I have no problem with the use of abbreviation if we have a normative table listing them. My question is all the long tag names that you showed before, are any of them from the UBL Library. GS: In our UBL library we do not go over the character count but we use the NDR rules for other industries and not just for the UBL library. MC: If we drop object class how does this happen. GS: Up to now there is no definition of how to drop off object class and we don't have a definition of how this would work with global elements. It is not always possible to drop off object class. SAP has exceeded 32 characters, we are using the NDR rules for our own implementations. EG: Would it be useful while not using abbreviations in the UBL library if we said that the NDR rules could be complimented with these other abbreviations. This would mean we do not imply that UBL has to use that approach. MC: I would be more comfortable approach. GS: This would be too complicated a specification with too many exception rules. EG: Gunther, what I proposed is exactly what you said. 3 possibilites 1. no abbreviations 2. always abbreviate 3. allow abbreviations. If you need to abbreviate then abbreviate but based on a list that we will give you. I don't understand why Mark thinks they won't use our list. KK: You have judgemental decision on whether something is abbreviated or not. This is a very weak position to defend. Either you don't do at all or do it all the time. For maintenance reasons if there are new elements who will decide on whether it should be abbreviated. If you make an abbreviation, make sure you have a predictable list, so that you can auto-generate the expansion of it. AG: If we use abbreviations they have to be consistent, I agree. We have a real problem that tag names will be more than 32 characters. EG: Which ones are longer than 32. AG: From CBL I see it as inevitable but I will come up with some examples for you. S: It is more a human language alot of these abbreviations such as Admin is not really an abbreviation. In the human language some people will consider some words to be full when they are not. MC: I agree with Steve and that is why I was against them in CCTS. I had to deal with acronyms and abbreviations for the US military and they are the world masters at that. It was an administrative nightmare. No matter how careful you are in publishing a list of abbreviations you will always have collisions with somebody elses natural language or constructs. One of my primary reasons for using global elements is reuse, if you stick in abbreviations you have undermined reuse. Who is going to be the Czar of abbreviations for UBL. You will have people from all over the world searching the registry. AG: They would search on the dictionary entry names. EG: There are 2 ways at looking at the abbreviation process. Either, you say we are doing abbreviations therefore AdministratorAddress will always be AdminAddr or there is something that triggers the abbreviations i.e. if the tag name is longer than 32 characters. GS: It is not very useful to have a registry with tag names only. It must store information about each component. If we look at the registry, therefore it is a good thing to assemble business documents together. I know 3 different registries for storing Core Components, their searching is based on dictionary entry name. What would we do with OSI, EDI? Should we spell out every acronym. AG: I can verify now there are alot of tag names pushing the 30 limit. MC: We did have a formal decision on this use of abbreviation so we would need to vote to reverse it. Hisano: I have been doing naming rules for UN/EDIFACT for 20 years and find sometimes abbreviations are ambiguous. Any abbreviation we use should come from the OED. Example is identifier, identification or identity which one do you mean by ID? MHC: From a procedural point of view we need to vote to reopen this issue. MOTION/MC: I make a motion we reconsider use of abbreviations. SECOND/EG: I second it. LS: We have quorum today so the motion is carried with MC abstaining. Mavis Cournane, Gunther Stuhec, Kris Ketels, Arofan Gregory, Matt Gertner, Mark Crawford, Mike Grimley, Eduardo Gutentag, Lisa Seaburg all voted, Mark Crawford abstained. EG: We will lay out the options 1. No abbreviations or acronyms allowed except the current exceptions. 2. Everything must be abbreviated according to a fixed list as per the OED for abbreviations. 3. Acronyms and abbreviations should not be used unless the total number of characters exceed 32. They must be abbreviated as per the OED. KK: If the rule is 30 characters and for one reason or another you have to extend it in another case. In one case you abbreviate it and in the other not. AG: How do you calculate the 32 characters. MC: We have not decided on how we are going to convey context yet. Arofan, we are going to have to go through those truncation rules regardless of whether we go for abbreviation or not. Option 2a could be that we create a controlled vocabularly and have an acronym board. EG: Mark you misunderstood what I meant in option 2. I am talking about a controlled vocabulary in option 2. MG: We were sure that we would have to extend the list of exceptions. I am sure that option 2 is the way to go. We should decide to add some additional exceptions. I am in favor of acronyms and not abbreviations. GS: In response to Kris, he is right. AG: I am assuming it is just element names we are talking about and not type names. EG: It has to be type also. GS: Agreed. AG: Before we put it to ballot why don't we come up with some proposed lists. MG: I don't think we should do that first. We should just go ahead and vote. EG: If we do it for types we will need a script. Can it be done for delivery. GS: Yes it can. MG: I think we should just allow acronyms EG: It would not buy you anything. MC: I have less issues with acronyms that allowing abbreviations and acronyms. S: As an application deliverer, I can see where Arofan is coming from. The amount of usage within the language is important for deciding whether abbreviation is necessary or not. MC: Since we have quorum can we vote and approve either option 2 or 3 provisio that option 1 fails. JB: Roberts did not consider this situation. The general principle is what we decide to do by common consent without going outside the bounds of the process by agreeing unanimously on how we are going to operate. MC: We have unanimous consent. We can either vote on option 2 or 3. MC: The results are 6 to 2 in favor of option 2 with 1 abstention. The minutes reflect that option 2 will take effect if option 1 is defeated by electronic ballot.
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.
Local vs Global Present: Mavis Cournane, Gunther Stuhec, Kris Ketels, Arofan Gregory, Stig Korsgaard, Ken Holman, Mike Grimley, Eduardo Gutentag, Lisa Seaburg, Hisano Sugamata, Luc Mouchot, Bernd Boesler, Matt Gertner. The way we will proceed is give everybody 2 mins to speak, please keep your comments to new issues only. Mark will then provide a list of options that can be sent out for email vote. KK: One of the design goals is to adopt benefits of schema and XML. Purely global elements does not respect granchildren of elements because global elements has no context. Schema allows name scoping i.e. meaning that the name of an element only has meaning within the context of its parent which means you don't have to repeat its characteristics as they are taken from its parents. Locally defined elements within global elements i.e. Complex Types. AG: Is context, structural XML context. KK: Yes MT: Elements that have simple types be local and elements that have complext types global. All the attributes of the complex types i.e. are local to their complex types. I propose global types and local elements. EG: When you reference elements you do the referenceing within a hierarchy. You are establishing a content model by referencing not defining internally. KH: I support local for writing stylesheet. Hisano: The user object has to be independent of environment. The usability of the component of the object i.e. global object in the element does not make it any more independent. The BBIE should be local and the ABIE should be global. GS: 3 more issues. Namespace hiding is a big advantage of global declared types. NS are always used for technical reasons. MC: The decision to reconsider does not uncompass qualified vs unqualified. GS: If you use global elements you will always see the ns prefix and that is a problem to separate technically by namespaces. It is not useful that you will see the ns in instances. My second point is my tests show that referencing across types is better if you use KEY/KEYREF. If you use global elements you are writing XPATH structures within the KEYREFS and you have to qualify by the namespaces. The third point XSI:TYPE can be used in global declared types only. My position is global types, local elements in all cases. MC: We have already taken a decision that all elements are qualified. MG: I don't think you understood what Gunther said. Pre-fix defaulting in instances is ugly. Namespacing prefixes are not necessary in instances. A side effect of qualified is that for global elements you have ns everywhere. AG: I have one concern, people not here right now would need to understand it. Below is a list of the options MC: The procedure is NDR has to revote option 1. If option 1 fails we do not have a standing position on this issue. Since we have quorum, and we consented unanimously to put forward our preferred choice then. Eve felt this was incorrect, and point of procedure was discussed. MOTION/MC: I believe that I have misinterpreted the decision on how to proceed this morning and I move that we rescind this mornings decision with respect to procedure. We need 2/3 vote. SECOND/MHC: I second it. MC: On this decision, we have a couple of things we need to go back and look at. MC: Let us revote this mornings decision on long tag names. My motion is that the following rules (Option 2) be accepted: [R 1] Element and Simple and Complex Type Names must not use acronyms, abbreviations, or other word truncations, except those in the list of exceptions published in Section XX. [ed note - section xx to be a section in the NDR document. Currently this section only include ID for Identifier, DUNS, and URI. [R 2] Acronyms and abbreviations will only be added to the approved list after careful consideration for maximum understanding and reuse.[R 3] Acronyms and abbreviations must only be taken from the latest version of the Pocket Oxford English Dictionary. The first occurence listed for a word will be the preferred item to be used. [R 4] The Abbreviations and Acronyms listed in Section XX must always be used. We also agreed that the supporting text in the NDR document will include a strong caution against identifying more than a handful of approved acronyms and abbreviations (numbers being bantied about were in the 3 to 5 additional abbreviations range). 7 yes, 1 no, 3 abstentions for Option 2 in terms of Naming Rules. MC: We now can also do the same with the Local vs. Global issue. We have 4 options on the table The Options are: Option 1 (Current option) [R1] All Type declarations MUST be global [R2] All element declarations MUST be global Option 2: [R1] All Type declarations MUST be global [R2] All element declarations MUST be global with the exception of ID and Code which MUST be local. Option 3 [R1] All Type declarations MUST be global [R2] All ABIE element declarations MUST be global [R3] All other element declarations MUST be local Option 4 [R1] All Type declarations MUST be Global [R2] All Element declarations MUST be Local . We polled the group using a Quaker poll and found that Option 2 was the most popular and Option 3 is the second most popular vote. LS:We are now going to move to voting on this issue. Only, the NDR SC voting members will take part in this vote. Motions from the floor FIRST MOTION/MC: I move to adopt option 2 as the NDR solution. SECOND:EG Kris Kettels: I move to amend the proposal to reflect Option 3 vice option 2. The motion to amend was defeated. We then had a vote and the motion on the floor (Marks motion) passed. The rules are: –[R1] All Type declarations MUST be global –[R2] All element declarations MUST be global with the exception of ID and Code which MUST be local.
Present: Mavis Cournane, Eduardo Gutentag, Gunther Stuhec, Stig Korsgaard, Mark Crawford, Michael Grimley, Lisa Seaburg. (All UBL) Sung Hyuk Kim, Thomsa Bikeev, Hisano Sugamata, Luc Mouchot, Bernd Boesler (ATG2 representatives) Discussion of week's schedule Local vs Global LS: Since the last F2F nothing has moved or changed in the NDR document. We need to come up with a list of issues, divide up the work and get it done. Local vs Global has taken alot of our energies and will be a large part of our debate and discussions. EG: Discussions are entrenched and we will not arrive at a decision ourselves. We should send it to the UBL list and vote on it. LS: Arofan Gregory said that he had a few more questions and might change his vote. LS: We do not have quorum but we could have a straw poll. EG: Since this is such a critical issue, therefore it merits being done over emial. MC: One of the reasons we have ATG here is to enter in to a detailed discussion on this issue. They have very strong ideas on this subject. EG: Who is ATG here. Gunther Stuhec, Mark Crawford, Lisa Seaburg, Stig Korsgaard and Arofan Gregory are members of UBL and of ATG. The purpose of a straw poll is an idea on how the positions are divided. MC: Let's take a straw poll. 4 for local, 9 for global. EG: Lisa should lead the discussions. LS: We have two hours today, Wed pm 12-17:00. Eve will call in from 12-2 on Wed to discuss it. In total we have 7 hours of discussion time. MC: We have put together a list of pros and cons from the October F2F. ATG have a list of pros and cons from their March F2F. As a first step we should review those to refresh our minds and give Gunther an opportunity to talk about his paper to set the stage for his discussions. We could recast on Wed combining the pros and cons from the two groups and Gunther's paper. LS: Our initial position was local. EG: Correct, we revised our decision to Global at the Burlington F2F. LS: Let's look at the F2F minutes 1-4 October 2002 UBL NDR SC Meeting. In these minutes we said This is a first cut of our analysis of positives and negatives: Local element characteristics: + Vocabulary can have multiple elements with same name Global element characteristics: + Fragment processing is uncomplicated + Can be reused directly - All elements must have unique names Qualified element characteristics: + Customizers can safely define unqualified elements . Instances can look clean with defaulting Unqualified element characteristics: + *Very* clean, simple instances - Customizers can't safely define unqualified elements - Unusual design choice; in most vocabularies all elems are qualified [Excerpt taken from the Minutes] EG: Back at the F2F in October we saw local elements have one thing that is positive i.e. a vocabulary can have multiple elements with the same name. A global element con is that they must have unique names within the unique namespace. GS: What did we mean by fragment processing? EG: When you have to take something from an instance to put in another instance or something from a schema into another schema EG: For local "Types are required to be re-bound to foreign elements in attempts to reuse individual components of the UBL Library" was another point. GS: I don't see this as a very negative issue for local. EG: for global " Going forward, there is a cost to ensuring that each new element name is unique." I don't really buy that. MC: I do, I think this cost is worth bearing. GS: I see alot of naming collisions if we use global. This is not a tool or perl script issue. It is more generic. The best example is identifier. The global declared element is ID. You have many different identifiers with specific restrictions. Sometimes you have to restrict identifier which is problematic for globally declared elements. The names of the globally declared elements will be very long. From my analysis some databases can't handle these long names. Also for truncation rules they are difficult to write for these long element names. I often truncate object classes. You have globally declared elements that can conflict with other ones. You need an awful lot of exception rules to restrict successfully. MC: Let's now look at the ATG Minutes to see the pros and cons identified. Venetian Blind – Global Types, Local Elements, May be qualified Pros a. Binding reflects OO serialization (.Net, JAVA) b. Supports type reuse c. well accepted d. makes for short tag names Cons a. Does not support element reuse (even if namespace qualified) except indirectly through binding the whole type in which it is declared to an element in the outer schema reuse b. Allows for the same element to be bound to multiple types c. Allows the same element name to be used for multiple semantically non-equivalent elements d. Requres type aware processor to be able to conclude the semantic equivalence of two elements e. Makes reuse of XPath based logic difficult (XSLT and content based logic) Garden of Eden – Global Elements, Globally Declared Types, FullyQualified Pros a. Instance document is semantically unambiguous b. An element in the instance points to the type c. Elements and types are reusable d. Does not require type aware processors e. Makes reuse of XPath based logic easy f. Supports building TBG required library g. Makes mapping between EDIFACT and XML possible at the element level Cons a. Not well known b. Makes for long tag names c. Increases file size d. Does not directly support OO serialization e. Does not support long term direction of IT f. The ability to extend using both type and element can create standardization issues g. Creates many more tag names than venetian blind (some estimates are in the hundreds of thousands) Much discussion on merits/drawbacks of each. Mark had mini meeting with TBG1 and laid out pros and cons of both. Consensus of TBG1 was: ¨ Global elements are preferred over local ¨ Semantic clarity in the instance document without reliance on tools such as XPath is a requirement ¨ The tag names should be harmonized with the CCTS naming conventions ¨ ATG should be delivering a semantically unambiguous glossary of tags [Excerpt taken from ATG Minutes] GS: I will now show my paper. See draft-stuhec-globVloc-02.doc. It shows more pros for the Venetian Blind approach rather than the Garden of Eden. One of my main points is inconsistency of tag names for global elements. MC: How is that a global element issue. Is that a library inconsistency? GS: No it is as a consequence of using globally declared elements. EG: I don't see the relationship. Here you try to design a system with several parts. If you want it to function in the longterm without breakage you would define interfaces and you would not want to integrate other people stuffs. The LCSC defines tag names which interferes with your architecture as they have to be globally unique within the namespace. Gunther's example is where they are inconsistent in their work. MC: Exactly this is a result of inconsistency within LCSC. TB: In system design I am responsible for my part. The system you have is very inter-dependent. EG: How does this problem step from local vs global. GS: If we want to have consistency where you define only one address to be used in the same way. What happens if the address of the organization is different to the party. MC: If you have in place a very rigid harmonization and approval process whose primary responsible is to ensure all the name issues have been resolved in a consistent manner do you still have an issue? GS: The problem is for example sometimes you qualify a specific structure of an ABIE e.g. BuyerContactType and SellerContactType. Sometimes you use Address which is very generic, and another time you are using very qualified and specific names. WE have seen if you are defining very specific, qualified names that makes the schemas huge with lots of redundancy. SK: Something I don't understand. I agree that there is a role for harmonization and for that to take out inconsistency. I do know mark you raised issues of inconsistency. MC: This is a different one. TB: Here you have one thing which is a question of policy that is dependent on people obeying rules. Another question is about a highly inter-dependent system. Agreed there will be harmonization. I am questioning this policy thing. What happens in our organizations is that the XML guys get hit by all the inconsistencies done upstream. EG: I still cannot see in what manner having local elements would prevent you from having inconsistencies. MC: What I hear you saying is that there is inconsistency in the application of CCTS rules. GS: I am saying that local elements would prevent inconsistencies. TB: Venetian Blind would hide all of the inconsistencies and would be very forgiving, however it would not improve anything. GS: No it would positively impact it e.g. BuyerPartyAddressType, SellerPartyAddressType. Defining a new aggregation BuyerParty, you will have for all the same aggregations the same names. If you wanted to define Address within BuyerPartyType you can truncate Address because it is locally defined and refers to BuyerPartyAddressType. The advantage is that you will always have the same tag names in it. EG: But they are from totally different types. For me that is a problem. If you look at it when you are reading the instances it can be very confusing because you have BuyerPartyTypeAddress and SellerPartyTypeAddress and hidden behind is the fact that they are different structures. TB: Does that matter for the machine. EG: No but the purpose of XML is that it is human readable. TB: Being able to parse and validate via the type is very elegant. GS: Truncation is very easy with locally declared elements. One of my customers wants to exchange 20m messages daily. EG: Use ASN1 then. GS: We don't want to do this. MC: If someone wants to do 20m transactions why not use EDI? GS: WE are talking about how we can use XML directly in our systems without mappings. One of the biggest disadvantages of EDI is mappings. EG: This is a different type of mapping. LS: Let's summarize what was discussed so far: Problems with Global - Inconsistency of tag names - Difficult truncation rules - Long names Positives for Global - Reuse elements and stylesheets Problems with Local - Tools must be type aware, stylesheet reuse. - Elements cannot be reused, only types. - no harmonization is done for local elements as there is nothing to harmonize. Positives for Local - Easier to generate tag names. EG: There are many attractive things about local but this was trumped by issues of reusability and it would take a very strong argument to convince me to go back. LS: You would only register your Types if you go local not your elements. GS: You can search the registry for types. MC: But let's say you used a different set of elements for types I have some real problems because they are not registered so you won't get type reuse as well. GS: That is not right. It is not necessary to harmonize the elements. MC: So TBG 17 (harmonization is no longer required How can you tell someone you used the wrong set of local elements. GS: These can be generated automatically from the dictionary entry names. It is not necessary to look at the locally declared elements just the dictionary entry names. MC: In the instance document? I can have 12 different elements called Name with a different meaning. We never agreed that our work documents were only focused on machine processable. They must be human readable as per our original goals. GS: They are human readable. MC: You have yet to give me a technical reason why our accepted solution won't work. TB: It is not about working or nor working. MC: That was our reason for review. We took a formal decisions. MHC: Yes he said it could not be implemented. MC: We have heard lots of "preferred" but I don't see what is not implementable. GS: I talked to Dave Carlson about these ones. The biggest problem is the implementation itself. One of them it does not align to the OO approach. You are defining some Types and some Objects may be based on those types. That is exactly what you are doing in locally defined elements i.e. defining types only and using objects based on those specific types. What we are doing in the Garden of Eden approach is defining elements additionally. It is very hard to do this implementation. Maintenance would have to be done twice. If you define global defined elements you have do maintenance on them and on the type. If you would like to express this in different interfaces in different applications it becomes very difficult. There is no way to represent globally declared elements in Databases you need pseudo-classes as global. This means MC: Why do I need to represent globally declared elements in DBs. GS: If we would like to reuse across applications. TB: Type based schema and instance based tag names are reused which is very high maintenance. People could parse against the instances or the schema. As a standard you would probably prefer to give people one option only. EG: We are only concerned here with schemas. We are counting on UBL conformant tools and to be UBL conformant these tools will have to do certain things in a conformant way. TB: If I am an implementer, you can use any parser but you will need some applications to apply business logic to the document. there are two ways to parse the message in two different ways. You can parse it in the current XPATH way i.e. tag based or you can parse it schema based. The way to do it is ambiguous. GS: I have an example See "Generating ABAP-Objects for SAP development environment" in draft-stuhec-globVloc-02.doc. MC: Is this a production system. GS: Yes. If you need some additional elements you must define pseudo classes that refer to a datatype. MC: If I understand, your argument is there is no way to handle global elements in the database. GS: Not just in our SAP DB. I have done a rationale Rose experiment also and you need to define pseudo classes also. If you generate SAX interface you will always see these pseudo classes and the developer will not know what their purpose is. Additionally, I experimented with Tamino and encountered the same issues. MC: You have stored the Types with all of the elements defined within them so what is the problem. GS: In the database table for example, what happens if the ID of buyer has different characteristics to shipping ID. You need 2 different elements. Tamino DB handles this as follows: If you use local declared elements it puts all the information in to one column but if you define globally the Tamino DB defines an additional row, one is called ShippingID and BuyerID automatically. This means you have different rows so you have to put the information in to two different rows. EG: How is this a problem. GS: This is not the normal way for DBs. You need some manual maintenance you have to group the information manually. You then get in to manual extensions. I am trying to always use the same model in each case. The biggest advantage of XML is that you can use the same model in different applications without transformation/conversions. You can develop your model structure in one environment and port it to another which is very attractive to us. BB: You don't have a separating tier. LM:For me Class is a Type, the Attribute is an element and we want to harmonize the types. It is not necessary to harmonize the attribute. GS: I am saying that I would like to harmonize the elements. LM: If the class is harmonized then so is the attribute. GS: The characteristics are described on different classes/types. If you define a new characteristic you define a new type. Summary of above implementation issues. Gunther experimented with Tamino from Software AG (native XML), SAP system (not native XML compliant), J2EE environment 1.3, Rational Rose and perl developed environment. The results he put forward were: - pseudo classes had to be used for declared elements in every application - additional maintenance has to be done to merge pseudo classes if they express the same information Tomorrow We start with the Common Core Component Types. We will present it and it won't take all morning. This will be led by Gunther. See draft-stuhec-ccc-09.doc.
Agenda items 1. UBL Context Methodology Overview 2. Code Lists 3. Namespace versioning 4. Embedded documentation Present: Eduardo Gutentag, Sue Probert, Mike Grimley, Gunther Stuhec, Mike Adcock, Garret Minakawa, Sunho Kim, Sung Hyuk Kim, Arofan Gregory, Hisano Sugamata, Mark Crawford, Matt Gertner, Lisa Seaburg, Mavis Cournane 1. UBL Context Methodology Overview - Eduardo Gutentag EG: We are on the fourth iteration of the guidelines and we received lots of very good feedback. Dan Vint you are not telling me how to do it and you are telling me not to use redefine which is being used in Acord. Dan explained the Acord process which uses an adaptor schema. See the NDR list for further details. Dans Proposal is as follows: You have the UBL schema and you can include it into another file where you can redefine elements using XSD extensions and restrictions. This extension is as per the CM guidelines. For all intents and purposes this is a method whereby you can implement the guidelines. From that point of view this is very attractive as it proposes a management method as well. When you redefine you are not parallel defining you are actually redefining and the only thing you can use is the new redefined element. There is one issue that many people will see as a problem. I am personally not sure it is but it is the fact that you are redefining the element but you are not changing its namespace. MA: An observation is that we have a payment system in the UK running for 35years. THis has been redefined several times. Redefinition is too easy and documentation does not exist for it. This is the same circumstances. THis is redefined and you have no way of identifying in the record which definition it is. EG: The difference in this case is that documentation is mandated for redefinition. MA: This is redefining the technical solution to a business requirement and I thought we were having business requirements on top of the technical solution. EG: The business requirement in this particular case is the context. MG: Conceptually I don't like it, as an XML geek it seems wrong and it could get messy. On a pragmatic level I don't see how these problems are going to manifest themselves. When and if we ever automate CM application this problem goes away. EG: I think that the redefine is easier to automate. Having a schema where you have the Address element defined 5 times and having it in 5 separate namespaces, being able to use any of those 5 and not being sure of which you should use, that is messy. The more I think about it the more I like Dan's solution, however, I am conscious of the fact that people will take issue with the fact that the redefined element does not have a separate namespace. We might add some attribute to the root to try and solve this. MG: I would be inclined to favour the redefined personally. MC: THe risks associated with redefine from "Definitive XML Schema" - Duplicate attributes. EG- It would not parse anyway. - Adding element declarations to the content model that render it non-deterministic EG/MG I don't understand that. MG: Have Acord released this to the wider world. EG: I don't know - Acord is a controlled environment. And our situation would not be a controlled one. The only way to do this legally from the UBL point of view (i.e. an XSD extension) is to document it and to document the context. The reason I wanted to talk about it now is so that people think about it. WE won't decide it now but maybe on Thurs. MG: The more I think about it the queasier I am about the whole redefine thing. It would not be a big deal to provide people with a tool for doing it. EG: Somebody has to write, test, and maintain the tool. Our tools and techniques committee is only one person. I don't see who can do it on time. MG: Let me think about what it would take. I am not volunteering. EG: THis is why we are talking about just guidelines at this point. MG: I think it is conceptually wrong and it is impure from an object oriented perspective. You could run in to trouble if you were generating java classes from derived schemas. Tools that do stuff with schemas is not going to know what to do with this. I am against it. EG: The part I like about it is the element of manageability that it gives you which the other approach doesn't. Perhaps we can come up with another way of doing it that has include/import types of things that gives you manageability without the overhead of redefine. EG: We should think about whether having Global types but not global elements would solve some of the problems of the chaos created by having to go up the chain every time you change an element. MG: I don't see why. EG: I am not sure. 2. Code lists - Lisa Seaburg LS: I have put the document up on the site. See the NDR portal and v03 of the paper. This goes through the way UBL is to be used using codelists. Starting at section 2: GS: I have a problem with the example <ISO3166CountryCode>, if we use this in our example everyone will use it and it is not the real one. LS: Let's go through Eve's comments. [ELM1] EG: I think it is right that it is doomed from the start. GS: How do you differentiate code lists in the instance. EG: YOu have to look at the schema. GS: You will not see any supplementary component in the instance. If you have a choice between 2 or more codelists for the same code e.g. Country Code. You can't see that in the instance. MHC: Yes, you have to go to the schema, unless you put the name in to the tagname which doesn't follow our naming conventions. GS: You have 3 codelist and each list there will be an enumeration. There is an attribute to store each version of the code list. Each version has the same name e.g CountryCode v1, CountryCode v2 etc. How can you use of these versions within your business document and within your XML instance. Right now Eve has a structure <IdentificationCode> <CountryCode V1> </> </> Is it efficient to put all the characteristics of the code list in the tag name. No it is not efficient and it is not processable. In our environment there are 40,000 different code lists which means you have to define 40,000 different tag names. EG: This element name CountryCode is a UBL element and it has things fixed. That means because the information is fixed it has to have a different name than anyother element that has things fixed. This is a problem. The fact that is fixed screws you up. The only way to fix this is to go back to LCSC and tell them that fixing it is a problem. GS; This is a design decision. EG: Where is this XS:element name="ISO33166". GS: This is not UBL , it is part of Eve's suggestion. LS: We have 2 codelists from UN/ECE that follow this pretty closely. EG: I don't know what the right answer is. It may be that it is appropriate to have different element names. One of the advantages of having it fixed is that the instance become smaller as there are all kinds of things you don't need to specify. In the element name reading without the schema in front of you, you have a good idea of where it is coming from. GS: We might not need any attributes. We would like to design serious business documents, which means implementors/customers have to handle 40,000 different versions/characteristics of code lists. LS: Our first choice is for us to use these codelists but not use them. GS: We are using the NDR rules for our own definitions. It is not very easy if you have 40,000 different tag names and interfaces. AG: This is not a problem for many people. EG: I think the problem arises because there are 2 kind of codelist - one is a stable one like ISO, relatively stable and versioning is not important, the other type is very unstable with multiple versions. The first category should be done fixed and this should be reflected in the code, the default for the unstable one should be defaulted and tag should be generic. They are two different things. GS: I would like to think of having one generic solution that would work for both. EG: I think we should ask Eve what she thinks about it when she calls tomorrow. LS: We made a voted choice in the minutes. We ended up voting for the multiple namespaced types. GS: We have 45 different code lists defined in the business documents. Maybe 15 of these are based on standards and the others are proprietary. SP: UN/EIFACT code lists are already in use. The ones that are working well will be used. Context is another issue. SP: How do we tackle that in a certain context a subset of a codelist is required. How does this happen automatically. AG: This does not happen automatically. EG: The vertical involved specifies which codes are being used which is a subset of the whole thing. The subsets will have to adhere to the NDR Code list rules. The main problem is tag names given the multiplicity of codes how do you avoid proliferation of tagnames. EG: You either have to have 40,000 element name tags or namespaces. You can deal with it in different manners e.g have one element code with attributes that tell you about the code, agency etc. Your application will either know what to do with that or not. In that particular case you can't have default or fixed attributes in the schema itself. GS: My SAP colleagues would like to use NDR definitions but we have to handle our customers varying requirements. We have to find the most efficient way to do this. EG: This example we have in the codelist document, is it an example from the UBL namespace. GS: It is just an example defined by Eve. LS: We have made decisions, do we have to open it all up again. Can we make some smaller changes and compromise. EG: This might be fixed with a tweak. LS: Gunther, read Eve's document and think about it. GS: I will do this tonight and I would like to see how this can be solved within Eve's rules. If I find any solutions tonight I would like to show this tomorrow.
Present: Mavis Cournane, Lisa Seaburg, Matt Gertner, Mark Crawford, .., Arofan Gregory, Jack Gager, Stig Korsgaard, Garret Minakawa, Jon Bosak, , Hisano, Luc Mouchot, Gunther Stuhec, Nigel Wooden, Mike Grimley, Eduardo Gutentag, Sue Probert. Local vs Global MC: We should revisit our last decision and our grading of pros and cons. ATG did their pros and cons of Garden of Eden vs Venetian blinds. EM: The costs in terms of Java binding of local vs global. Basically, Joe Fialli, spec lead of the JAXB spec for Java data bindings was very careful not to prefer any one schema design over another. His team did experiments with SAML and UBL. ANy schemas that have global elements, because they have alot more power than local it does generate more code. Global could potentially serve as a root element for a schema, serve as the head of a substition group, content you could fill in a wild card content somewhere else. One of our use cases was for tweaking existing content models. Also it is useful to reference a whole element not just a type for building new content elements. The extra code developed would be a trivial java interface. A global element can be referenced from a foreign content model, which is interesting for our use case of building new document types out of existing unchanged UBL parts (not for our other use case of tweaking content models). This is in addition to your list of other global element features above. Problems that you could not reuse the same element name. If you have done your design to resolve clashes then the generated code does not care. It is not disturbed by the fact that you artificially ensured there were no name clashes. THe cost is that you now have an interface for that element. What about if we know there are elements we don't want to reuse. He said I could imagine a configuration that would not generate interfaces for those elements. Eve said you would not actually not want to generate an interface. In other words, if we really want these elements to be reusable, the interface would still want to be generated, so we don't save anything with this idea. AG: If you are generating the code from scratch there is not alot of cost. MG: In support of Gunther's paper. It seems to me we are trimming our finger nails with a chainsaw. I don't know why everything is global regardless of context and location. More reasonable would be to have global types and if you need a global element invent a separate schema and import it. EM: That wold make for anomolous results. MG: It does not mean they are not reusable. GS: My biggest issue is that you define for every component a global element. IF you do a direct binding to any programming language, you have to define for every tag name you have to define a variable. This is not very maintainable EM: If the code maintenance problems are the issues, I think we really need to go through my comments. EM: Let's go through my comments on Gunther's paper on March 12 2003. What about people who have a problem with things that are not in the instance. Non type aware processing is problematic for them. 1.The assertion it would be hard to find out which child elements must get the object class qualifier. It is a modelling question, as modelling work will distinguish them as necessary. It is true that you have to do "cynical" modelling. There is a responsibility to resolve clashes at the modelling stage. It would be more efficient if we did not have to do that. Is that cost too high? GS: I agree with you. If you have many different business requirements you don't have the normal form. The Address within BuyerParty differs from the Address in SellerParty. How do you name the Address of the SellerParty. Should we name it SellerPartyAddress? EM: Good question. You have to look at the context in which you are defining the thing. THe modelling process has not filled in the context drivers very successfully to date. Chances are they are two instances of some generic thing that does not yet have an expression in the library. MG: I agree with Gunther's conclusion but it is not the strongest argument. On the one hand we don't want to go though a rigamarole to decide what is local and global. But if we are deciding when to truncate names, then we are doing something similar in the modelling stage. So we are not reducing the complexity or the chance of error. EM: The reason why I am really not happy to decide on an element by element basis if you were to decide the inconsistency you would provide a developer would be enormous. However, if it was whole bunches of elements like leaf nodes were to be one way that would be different. MG: I believe everything should be local. If we want to provide global elements I would have a separate schema file that has global elements for all the global types. EM: I am sympathetic to that as we have not been very good at weighing use cases. MG: THe alternative to me is too much burden on the modellers. GS: It is not a good idea to decide on an element by element basis. We are using the CCTS as the basis. It is easy to extract the tag names of each local element out of these dictionary entry names. EM: There is a deterministic way that we could proceed with local elements. Matts suggestion that you have parallel global elements is not practicable timewise. MG: Why not just qualify everything in the global element names? 2. Long tag names EM: The model should remove redundancies. It does not make things so artificially different i.e. PartyName. GS: The problem is we are removing two names PartyName ( has rep term Details) and ShippingContactName ( has rep term Text). EM: What do we want to do when things are structurally different but semantically the same, is really what we are trying to address. I can see that local names work in those cases. GS: Take Address. We globally declare Address. Another modeller extending the library sees that this Address cannot be used in the aggregation of BuyerParty because the structure is different. So he makes PartyAddress. Another modeller will need a SupplierPartyAddress and will generate that. If you define a different structure based on Address you will need a new name and lots of exceptional rules will be required to define this name. The only way is to use the Dictionary entry name. THese are very long and will have redundancy. EM: I don't buy that argument. To create different elements for different structures does not bother me. The names of the elements might occasionally be longer. A tiny bit of adjustment might be needed in the binding but this is because we have not been modelling in a very tight way. I don't think type aware processing is hurt by global elements because they are bound to the same types they would have been anyway. Type aware processing is not going by element names. EM: This is a straw man on top of a strawman. GS: I have looked at some SAP examples where we need more qualifiers to identify specific structures. EM: This is true for some names but others won't need that level of qualification. GS: Let's look at Identifier. EM: It is possible if we compromise we can resolve this for leaf nodes. Types won't get that long if they are distinguished structurally. GS: You will have the same long names if you use aggregations. Address is a huge aggregation with lots of difference. EG: That is what we have the extension mechanism for. EM: If you add in industries and business context variations there is an infinite number of possibilities. Let's solve the problem for the stock UBL library first. EG: What I was saying is for a whole industry that is what Context Methodology applies to. It is a red herring to say that tag names grow with context. The whole point of Context Methodology is to do this correctly. GS: I agree with Eduardo that CM has a role, therefore it makes sense to use globally declared elements but without qualifiers because qualifiers are based on context which makes tag names very long. EM: Make it local whenever you have a qualifier. EG: There is another issue of role context within the tagnames. How does that play with Gunther's proposal. GS: Remove role from the tag name. EG: If we do that at this point it is fairly late to do that. GS: It is the only possibility to get consistency. EM: It is intriguing. The modelling is not very context focussed right now. It would be a good exercise and try and apply these things as explicit contexts. I am dubious that it is right to draw a global local based on context or lack of it. Qualifiers are not exclusively used for context differences, look at HouseNumber. You could just call it Number but for human understandability you want to qualify it. GS: HouseNumber is a property term. EM: Ok, I can buy that. WE should define qualifiers based on context. MG: How do you solve name clashes. GS: One possibility would be to define for each context driver and attribute for example a global attribute group and put the contexts into the attribute group. EM: I thought you were talking about making qualified elements local? The rest would be global. That would be cheap way of generating global elements out of our system. MC: I am looking at the spreadsheet. If we strip off the qualifiers we would kill reuse. Are you suggesting that we strip off the object and property qualifiers. GS: I am saying most of the elements in the spreadsheet are completely wrong. Look at StartDateTime on L629 (OP7 reusable) in the spreadsheet. Start is not a qualifier, it is a property term. The qualifier is defined by the context drivers. AG: This is coming to the fore in LCSC. I agree you could do what Gunther proposes without breaking anything. GS: I have seen with BBIEs that I can remove 80% of qualifiers because they are part of the property term. StartTime is a complete property term. That means you put Start in front of DateTime. AG: You shift the qualifiers into the property term so you don't lose them. GS: ValidityPeriod is another example. AG: If we do this we would get shorter tag names. GS: We need to look at how we can handle everything. We have alot of property qualifiers that are really specific e.g. Shipping, Settlement, Seller. OrderLineMinimumQuantity becomes LineMinimumQuantity and this can become MinimumQuantity. EG: This should make global more palatable. GS: How do we handle all the qualifiers. NW: We would use the property qualifier as an association to link two aggregates. The qualifier is part of the property term. 3. Redundancy EM: THe dictionary entry name is a full name. Are we considering giving this full name to any element? No absolutely not. Our truncation rules will result in most cases in names that won't be the dictionary entry name. GS: If you have a different structure for the same name, you need rules to define these names and the only way to do this is the dictionary entry name. EM: You are talking about a naming design process. Bill Burcham demonstrated that there is not a great deal of overlap. AG: The whole point of the exercise is to agree on structures and assign them meanings. If there is a structural difference then it should be semantically different. GS: I am agreed it would be a different type but you don't have to have a different name. EG: given two types A and B, that are completely different, you could still have two local element Address, both called the same, one of type A, the other of type B; if the differences between types A and B are small that would be ok; what if the differences are enormous? When is the difference enough to use different names? GS: It is easier to change types than attributes in classes for implementation. EG: In that case in every definition of the elements that make up an element we would always have an element called A, B and C bound to different types because it is easier. AG: I am not sure you have won that point with local elements. Developers will implement what their customers want. GS: They will implement what is easiest for them. AG: Make the link between a venetian blind approach and your argument. MG: I am reconsidering my stand. EG: I would agree to a compromise. Most elements should be global perhaps, if there was a good criterion to indicate which would be which. MC: A step further would be criteria to ensure uniformity and consistency of the local elements. The biggest problems is that within certain circumstances is the ability to harmonize across a large number of business areas using local elements. EM: You can build it, but in an XML library types are no where to be seen. Type information will not be in the instances. You would have to require alot of system specific stuff. MG: As a compromise, what I suggest is reference the types inside local elements and define global elements separately. But don't reference the global types within the content models. EG: It is like throwing a scrap. EM: I actually agree it is counter intuitive to have everything global. The reason I am tempted to do it is because of the second use case and we have not substantiated it very well. The whole point of the library is to be able to do that. GS: We can do it 2 ways. One way is to say the approach does not matter. The instance must be the same. One group uses local and the other global. Another way is to use a mixture of global and local. All aggregations will be globally declared and all Basic Information Entities would be local. Frank Van Damme told me that the BBIEs are not reusable and therefore must be local. MC: I want to respond to what Gunther said. BBIE reuse in CCTS raised by Frank was not completely agreed by CCTS. GS: I am also saying the basis of every tag and type name will be the dictionary entry name. In our NDR specification we have the rules on how to generate tag names from dicitonary entry names. EM: I could certainly support a global aggregate and local basic approach. The cost is disambiguation. 3. Inconsistency in names EM: A legitimate concern. If we are looking for pure consistency we are going too far. If there is semantic or structural variation then perhaps it is right to have naming variation. Your literal XML instance should express differences that exist. We are really just arguing about the degree of difference. GS: How can you define the tags names? How do we define address for another aggregation? Do we define BuyerAddress or Address EM: You should have a BuyerAddressType that is derrived from AddressType. MC: LCSC has gone too far in their application of qualifier terms and should revisit the use of them. They should build a controlled vocabulary of qualifier terms. I am not in agreement that we should drop property qualifiers from the tag name. I would agree not to include the qualifiers in the object class. AG: In this discussion Mark, what we do internally is one thing, you can't know in advance what people who use it will do. EM: I think this is good i.e. to rationalize our use of qualifiers to help with our local vs global decision. EG: I think a compromise is better than the extremes. MG: I would summarize the 3 problems with global elements as follows: 1. Tag names are longer and more unwieldy as compared to local elements. 2. It seems conceptually not to be correct. 3. It imposes additional burden on automatic processors if tag names are created just for reasons consistency but aren't used. This can create a lot of unnecessary overhead. My solution In content models of all elements use local elements that reference a type, lop off all qualifiers and then have global elements defined for all of those types in a separate file that use the fully qualified name with all the qualifiers. EG: It would create instances that are totally different from each other, the name of the tags would be different dependent on whether you use local or global. Validation would be difficult. MC: Everything I have heard so far does not give me a technical reason why our global decision is broken. There are lots of subjective ones. It is clear that there is consensus that some compromise is the way to go. If LCSC revisits the qualifier issue alot of the problems with long tag names goes away. That in conjunction with the truncation rules i.e. not including object class qualifiers in all cases will significantly reduce the tag names. It seems to me that there are a limited number of circumstances that lend themselves to use as local elements in a way that can ensure consistency e.g. code and ID. I could support that sort of a modification. EM: I am some what sympathetic with Mark's call however, I have come to believe that the use cases we have been pointing out i.e. non-type aware instances are perhaps as not compelling. We have been talking about XPATHs being clean with local elements. You have to start from the root for local names to get clean XPATHs. This could be a really long XPATH. If implementers like Gunther tell me that there are implementation problems with global then I have to appreciate that. GS: The biggest con of global elements is the maintenance. MG: In response to Mark. As far as a lack to a killer objection there are some that have been mooted. Super long tag names could be a complete showstopper but that is not a far criterion. Eve made a good point, Gunther and I both programme this stuff and that needs to be taken in to account. Regarding her point, Do we need global elements at all?? I think we should get rid of that grab bag and the grab bag of UBL types should suffice. EG: You mean the types should be used for reuse. MG: Yes MC: I disagree - if you are trying to build a reusable library stored in a registry, you can't store local elements in a registry and have them stored and be semantically clear. Trying to search a registry is not possible if you go local. Tag name size is disingenuous. I cannot enforce harmonization. If I declare a type in one schema and another one in another schema with slightly different names and they have the same semantic value, I can't tell that you can't use one type because the other one exists. You would get a proliferation of types. AG: One of the most common things people will do with UBL is to contextualize it and they will need a library of types with standard names. I think global elements are vital for extension and customized. EM: I don't think global elements help you with this. Global types are what you need for extension and restriction AG: Alot of what I do is reassembly and we need global elements. Most XML developers are working from instances and they could become confused. We need global elements and I have changed my mind on local. I agree with Mark. SK: In terms of the length of tags I agree with Mark. GS: I am looking at the biggest advantage of XML is the ease of implementation. You don't harmonize just elements but also the structure. You find the structure in the types only. It is enough to harmonize types. For direct implementation local is the best. NW: Our use is to pick up from the UBL library and assemble in to our own messages. We want to be able to reuse the core library. We certainly wish to remove most of the use of qualifiers and this is acceptable to NDR. The only time we would use a qualifier is when it is a context driver. MG: I definitely feel this was a helpful discussion. The fundamental point of contention is whether people will understand the distinction between types and elements. It is possible to harmonize with local elements and global types. People are not used to doing it and it could lead to confusion. We are not ready to make a decision and work through some more examples. JB: My chief concerns are getting this thing done and adopted. First of all, readability is important and it is not going to be read just by experts. For adoption you have to design for a much lower level of expertise than what people are assuming, just look at HTML. For alot of people reuse means copy and paste. I don't know what those ramifications are. The single most important factor in adoption is training. From the standpoint of time, we are out of time. We won't debate this longer than to get this decided procedurally. From the standpoint of getting the job done let's make the smallest adoptable change to what we have already.
Code Lists AG:The issue we want to put to Eve is as follows: What we made provision for in the code list paper is very good for ISO code lists that are fairly standard and static but that is less ideal for more proprietary unstable code lists, where they agree on a subset of a code list. You would have to invent hundreds of different code lists. EG: Not anymore as they would all be local. AG: Should we create something else? EG: No because they are local. EM: I talked to the Open Metadata Forum, David Weber thought you had to do stuff at the application level. THis only makes sense as an option if it is static enough. If it dynamic use the generic code type that gives you all of the attributes that you can fill in at will. The best you can do is assign the metadata and have a string value. AG: Would validation of dynamic code lists be done by a web service. EM: At that meeting there was some suggestion of that though there were objections too. We did discuss what to do where the code list is an orphan. The generic code type would mean that you would not need an adaptor. MG: The right place for a web service would be in an annotation. EM: I would do that in a post UBL 1.0 world. We should provide advice on what to do when not to create a module. AG: We have a generic code type and an existing mechanism for handling static code lists. I am in agreement with Eve that we do not know enough about web services right now. EM: I got some feedback from Farouk 1. people are thinking what we advocate in the code list paper is the only possible way to do code list, and Farouk wants us to advocate a format that would hold all the data about the code list and generate the schema representation from that. AG: Should we advocate which solutions are appropriate for which kind. EM: We can do it, but something like classification scheme is optimized for that. For UBL purposes we really do need XSD but for us the source format is not that important. AG: We don't really care about the classification scheme. EM: I am bringing this on Farouk's behalf to the table. AG: I don't think there is any question about making the source format normative. AG: Should we allow people to add their own attributes to our own generic code type. EM: It is just a customization like any other. We should talk about that in our code list paper. AG: If you want to supply stuff for the paper I don't mind adding it in. I will deal with the prose if Lisa will coordinate it. LS: Yes I will. AG: The idea is that you want to get into the document that you would have a source format based on classification scheme. We would not want to make the classification scheme normative but we would like a rationale for this in our document. We have a very tight timeframe for it. Farouk: I could try writing something up after hours. Right now I am busy with XML Europe. Maybe after tuesday? EM: To my knowledge there is no official body that has made code lists for tri-body bi-body values. As UBL we could do some codelists for those and they would not have any ISO dependencies.
Present: Mike Grimely, Gunther Stuhec, Matt Gertner, Mark Crawford, Jack Gager, Lisa Seaburg, Mavis Cournane, Stig Korsgaard, Hisano Sugamata, Common Core Component Types will be worked upon. We split up in to 5 groups to work on them. AmountType CodeType DateTImeType IdentifierType IndicatorType MeasureType NumericType QuantityType TextType RateType URIType The tasks assigned to the group were to look at the latest version of Gunther's Common Core Components document with a view to: structuring the component correctly provide definition informatin provide use information provide structure information details and value ranges Rules Facets for content components Examples XML schema.
Joint NDR LCSC TG: We have been reviewing issues that have been passed to us that we think reside with you. Let's go through our list. Issues 1. The name of documents How do we express document names within namespaces. We need a document naming convention. File names are the physical implemention, the other is the logical name. See Gunther's paper for a proposal on how we can do this. Action NDR to put it on their agenda 2. Digital Signature David Burdett presented some issues to us. We need rules from NDR. We have a business requirement for this. 3. In terms of the virtual world i.e. the way we want it to appear to the world is bloated common aggregate types. WE would like to have one virtual library and if we are not implementing it correctly in the current schemas we need a better set of rules. We don't want to identify in advance what is reused so why not put everything in there. 4. Embedded punctuation in names We need a rule. There is one - strip it out.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]