[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Agenda UBL NDR SC 16 July 2003
The NDR SC Weekly Telephone Conference call is 16 July 2003 at 10:30 am Central (8:30am PDT). ############################################# STANDING INFORMATION FOR UBL CONFERENCE CALLS U.S. domestic toll-free number: (866)839-8145 Int. access/caller paid number: (865)524-6352 Access code: 5705229 ############################################# 1. Roll Call and Welcome from the chair (Mavis) Regrets Eduardo Gutentag 2. Adoption of agenda/schedule planning Upcoming Call Schedule: July 23 - Mark, chair (Clist & NDR 1.0 OASIS review) July 28 - Aug 1 - Face to Face Montreal (Process OASIS NDR/Clist review) 4. Review of rules issued to list for discussion - Rule 105 [ID/IDREF MUST NOT be used.] See Dan's comments [This seems a little overboard. I guess the corresponding rule is that key/keyref will be used to implement simple ID/IDREF relationships. Has anyone verifed that this is something that the tools support? I know they will manage ID/IDREF for me, but I have doubts about any other mechanism for making relationships.] - Rule 103 Substitution Groups [Substitution groups MUST NOT be used.] See Eve's comments [Does this mean that the normative UBL schemas must block element substitution so that customizations can't use it, or that UBL must not itself define substitution groups while letting customizations do it, or...?] - Rule 102 [The absence of a construct or data MUST NOT carry meaning.] See Tony's comments [I object to this rule on the basis that it seems unprovable. How does one guarantee that the absence of something cannot never imply something meaningful? I suspect that the idea behind this was something like "absence of an element should not be used to imply that the element has a null value", or something like that. Can someone who was around for the creation of this rule comment on what the idea behind it was? ] See Jim's comments [Although I've contributed next to nothing to UBL, I do seem to recall a discussion around this that is easily understood in the form of an example (totally contrived) that would violate the rule: "The CustomerID element may have the optional attribute customerIDType. If that optional attribute is missing, then the customer ID is a DUNS number." (Yes, I'm aware of W3C XML Schema support for defaults, but that's beside the point and probably not relevant at all given that the rule is not stated in the context of XML Schemas.)] - Rule 100 [[R 100] Union technique MAY be used to merge data types. UBL: Not applicable. Therefore, SHOULD NOT be used. (Code lists are excluded from this rule.)] See Dan's comments [How about: [R 100] Union MAY be used to create new simple datatypes as long as those types are not enumerated types (code lists).] - Rule 99 Simple Type Restriction [Simple Type restriction MAY be used.] See Dan's comments [This rule seems a little strange to me. The implication is that we have gone through all the schema capabilities and have indicated yes/no as to what can be used - is this true? If it is true, then I would recommend one rule that has a table of all the "features" with an indication of their use. It will be easier to find and maintain.] - Rule 98 [Built-in Simple Types SHOULD be used wherever possible.] See Dan's comment [Should we be masking the datatypes to protect against any future changes in definitions or other technologies? For instance xsd:boolean allows 0/1 and true/false - do all languages implement boolean this way? Will another XML schema language define boolean this way, or will it add yes/no? I would suggest adopting and specifying the UBL definition of the datatypes (for now they might be exactly what is in schema), but we don't use the schema types directly. So I would defined a ubl:Boolean that restricts xsd:boolean and then use ubl:Boolean everywhere instead of xsd:boolean. I belive in the long run this will be a useful "protection" from technology change.] - Rule 97 [Mixed content MUST NOT be used (excluding documentation). Duplicate: See Rule 25] See Dan's comment [Hoefully Mixed content is defined somewhere in a glossary, if not please add a description here: An element has mixed content, when it allows both data and additional element content.] - Rule 96 [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.] See Chee Kai's comment [Objection : Stating two versions of schemas that are otherwise the same except for documentation is a user-level optimisation/preference issue that shouldn't become a hard-rule from UBL/NDR. This is not to say that we cannot publish as a non-normative add-on, or reading aid or optimized version (assuming documented version is normative). Suggest removing it.] See Dan's comment [Removing it allows one to do or not do this. I believe the general request is to provide these two forms of the schema and there should be a rule/requirement that states this. I'm fine with the requirement to send both, but I think it should still be a stated requirement/rule.] See Tony's comment [I am *completely* opposed to the suggestion that users can filter annotations out of their Schemas if required. My experience is that only the < 1% of people who take part in XML committees have the confidence and experience for that. Worse, it just introduces an unnecessary, globally-distributed quality control issue. If it is so easy to filter out the documentation, then let us do it just once ourselves for everyone on the planet, and issue two equivalent normative Schemas, full-fat and low-fat. I'm happy to contribute an XSLT script or Java class to do the job, if it is too hard to do from the Schema generation tools.] See Chee Kai's comment on Tony [Sorry, Tony, I am VERY STRONGLY against having more than ONE normative schema. Taking a step further based on proposed "normative optimized schema without documentation", why can't people ask for "normative optimized schema without documentation AND without whitespaces" (ie, one long line of "optimized" non-fat milk?), and why can't people ask for "normative optimized schema in compressed WBXML binary format", and all sorts of other "normative" versions? Where does that stop?? So, no, please don't open the pandora box.] See Bill's comment [I think we should remove this rule. A user can filter out annotations if they are unwanted.] - Rule 95 [[R 95] Wildcards MUST NOT be used. ATG Decision: ACCEPTED. Wildcards MUST NOT be used. Editors Note - does this include Any and AnyAttribute?] See Dan's comment [The wildcard for elements is Any, the wildcard for attributes is anyAttribute and there is a wildcard for the datatype as well anyType and anySimpleType. Because the question was asked, maybe these should all be listed as an example.] - Rule 94 [The nillable attribute MUST NOT be used] See Chee Kai's comments [Amendment Required because prohibiting xsd:nil does NOT equate with prohibiting empty content element. Suggested change: [R 94]: The nillable attribute MUST NOT be used. Empty content element MUST NOT be instantiated UNLESS it is expressly a user-intended indication to instantiate empty content for a given element.] See Dan's comment on Chee Kai [This isn't quite right. In schemas only elements of type string can be presented as empty in a data stream without using the NIL attribute. The user indication that nil is the appropriate interpretation is to use this schema attribute (or we have to create our own method). We need a statement more like this: Any element declared to have data, must not appear in a data stream as an empty element. Elements declared as EMPTY may only appear in the data stream as an empty element. This rule then prevents the use of the nillable attribute in the schema definition and the corresponding xsi:nil attribute in the date stream.] - Rule 91 Types [All type declarations MUST be global.] See Dan's comments [I would modify this rule to be: [R 91] For reuse and extension, all types MUST be named, which then requires their declarations be globally defined.] - Rule 90 [The Abbreviations and Acronyms listed in Section XX must always be used.] See Dan's comments [ This should be combined so there is only one rule #87 [R 87] The only Abbreviations and Acronyms allowed for names used in the schemas or datastreams are listed in Section XX, ie. Element, attribute and Simple and Complex Type Names. Code list values are not controlled by this rule. [Editor's note: Section xx to be a section in the NDR document. Currently this section only includes ID for Identifier, DUNS, and URI.] See Mike's comments [That doesn't really capture Rule 90. I think two rules are necessary: [R 87] The only Abbreviations and Acronyms allowed in the naming of Element, Attribute and Simple and Complex Types are those contained in the list published in Section XX. [Editor's note: Section xx to be a section in the NDR document. Currently this section only includes ID for Identifier, DUNS, and URI.] [R90] The Abbreviations and Acronyms listed in Section XX MUST be used when referring to ( or 'in the place of'?) their corresponding references.] - Rule 89 [Acronyms and abbreviations must only be taken from the latest version of the Pocket Oxford English Dictionary. The first occurrence listed for a word will be the preferred item to be used.] See Dan's comments [I would change the text: [R 89] When the use of a new acronym or apprviation is approved fo ruse in UBL documents, the acronyms or abbreviations MUST be taken from the latest version of the Pocket Oxford English Dictionary. If more than one value is provided it should be the first occurrence listed for a word will be the preferred item to be used. Do we need something here to handle possible collisions with existing abbreviations? What about abbreviations that make words that may/may not be used elsewhere? Seems like this rule or the previous one that said they can be added should state some additional requirements (assuming you agree we should avoid these problems) Also what happens if we agree that we want an abbreviation and one is not in the dictionary, should we state a method for creating one, or should it be that we don't use the abbreviation? I have seen a general rule for creation (when they don't exist other wise) to be: "Drop all the vowels from the word."] See Tony's comment on Dan [>I have seen a general rule for creation (when they don't exist other wise) > to be: "Drop all the vowels from the word." Yes, that is the standard rule one uses to make acronyms accessible to native english speakers, and inaccessible to everyone else.] See Dan's comment on Tony [I didn't say anything about clarity ;-) it just gives you an abbreviation. I don't know that any abbreviation or acronym is going to be useful for a non-native speaker. By the way I'm having enough trouble with BIE and ACC and BCT in trying to figure out what these really mean. Even when expanded they don't mean much.] - Rule 86 [In the context of a schema, information that expresses correspondences between data elements in different classification schemes ("mappings") may be regarded as metadata. This information should be accessible in the same manner as the rest of the information in the schema.] See Bill's comment [What do the terms "classification schemes" and "mappings" mean in this rule?] - Rule 85 [Instances conforming to schemas should be readable and understandable, and should enable reasonably intuitive interactions.] See Dan's comments [I don't think the Instance has anything to do with the readability and understandability. Seems to me this should be a requirement for the schema design/generation process. This seems more appropriate: [R 85] Schemas should be designed (or generated) such that instances conforming to them are readable and understandable, and should enable reasonably intuitive int[eractions.] See Mike G's comments on Dan [ [R 85] Schemas should be designed (or generated) such that instances conforming to them are readable and understandable, and should enable reasonably intuitive interactions. Better, but I'm still wondering if the judgment of such things is too subjective for a rule ...] - Rule 84 [UBL messages must express semantics fully in schemas and not rely merely on well-formedness.] See Dan's comments [What are we really trying to say with this rule? Is that any UBL document should have a matching Schema? Should there also be a statement about validity based upon that schema? I would think something like this is more appropriate: [R 84] Any UBL messages MUST have a corresponding schema and the data stream must be valid based upon that schema. You should not rely merely on well-formedness when defining and building a message..] See Tony's comments [I don't think Schemas could ever be said to capture semantics. They can capture some of the business rules, but I rarely can they capture all of the business rules. I'm not convinced that trying to modify or adjust real business rules just to fit in with what Schemas is a good idea. Let me reword this in English, or a close approximation thereof: I don't think Schemas could ever be said to capture semantics. They can capture some of the business rules, but rarely can they capture all of the business rules. I'm not convinced that trying to modify or adjust real business rules just to fit in with what Schemas can do is a good idea.] See Mike G's comments [Or: [R 84] All UBL messages MUST validate to a corresponding schema. You should not rely merely on well-formedness when defining and building a message.. ] - Rule 83 [Trading partners may agree on other character encodings to use among themselves. It is recommended in all case that encoding declarations be provided in the XML declarations of UBL documents.] See Dan's comments [This seems to weak. I would change it to read: [R 83] UBL documents MUST always identify their character encoding with the XML declaration. It is also recommend that for protability that UTF-8 or UTF-16 be used; although trading partners may agree on other character encodings to use among themselves.] - Rule 82 [ UBL documents must use the same legal characters in XML character data that are listed in the XML Recommendation. Including tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646.] See Dan's comment s [ I would change the rule text: [R 82] UBL documents must conform to all the requirements of the most current XML Recommendation. Why are we worried just about these characters. I don't know that this is even required, but if you want to keep something for this rule, then I would make the more general and inclusive rule as above. Otherwise its like, "Oh all I need are these characters I can forget about all the other XML requirements".] - Rule 81 extending [[R 81] A UBL message set may be extended where desirable if the business function of the UBL original is retained., but the message exists within its own business context. ] See Mike's comments [Recommend: A UBL message set may only be extended if the business function of the UBL original is retained., and the message exists within its own business context. ] Recommend: A UBL message set may only be extended if the business function of the UBL original is retained., and the message exists within its own business context. - Rule 77 Duration [Duration may be expressed by the BCC Duration.] See Dan's comment [Also is this wording a little weak? If I have a duration I have a duration and it should always be represented with the proper BCC. When or why would you allow something different?] - Rule 76 Point in time [The intervals in a point in time should be represented by a single BCC indicated by the choice operator i.e. FrequencyDuration, FrequencyYear etc.] See Tony's comment [I don't see how a point in time can have intervals. I think this needs rewording, at the least.] - Rule 72 Representation Term [For each representation term the equivalent data type must be used i.e. if the representation term Date is used, then the corresponding built in datatype xsd:date must be used.] See Dan's comment [Wouldn't it be better to have a single rule and table that lays out the relation between the representation term and its data type (maybe even the BCC involved)? If we did that there would be one place to look this information up and we could remove the need for new rule with the additions of new types and remove rules like this and #68 which seems to be a generalization of this without the specific mapping. If you need something specific to report against, if could be Rule #72-Date or Rule #72-Decimal.] - Rule 71 Period Details [A period can be expressed using the Aggregate Core Component (ACC) PeriodDetails. The ACC is divided into 3 representation types, Date, Time and DateTime. One of these must be selected. Each option has a start and end date, start and end time or start DateTime and end DateTime.] See Dan's comment [This is even weaker than the BC Duration requirements. Also there is an explanation of the design that I don't think should be in the rule. Here is how I would change this based upon current design, if you agree we should be more specific in the requirements, then may would change to must. Rule 71 Period Details [A period MAY be expressed using the ACC PeriodDetails.] Also we are not consistent in how acronyms are spelled out. BCC used without an explanation but here we spell out ACC. There should be a standard glossary that has all these terms with maybe a pointer to control documentation for the definition.] 5. Action Items and Issues: A. Modeling changes and schedule for schema fixes for XML instances and FPSC, B. Other issues or comments per the 0p80 Review? 6. AOB 8. Adjourn Next NDRSC teleconference call is 23 July 2003, Mark Chairing.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]