Arofan, Gregory, Arofan wrote: > > Phil: > > Let me try to answer your points in a general way: > > First, when we talk about code lists I am assuming that we are restricting > ourselves (as we did in xCBL) to those lists of commonly used, well-defined, > externally-maintained codes that come from places like X12, ISO, and the > UN/CEFACT Codes Working Group. For xCBL, we harmonized these codes in some > cases, and in others, we chose to subset them for our own uses, but we have > clear maps back to the definitions commonly understood in business today. > > We *cannot* use any controlled construction in UBL - be it an element or > attribute name, or a value in an enumerated list - that we do not in some > way completely and unambiguously define. Otherwise, we have failed in > creating a useful language for e-business. > > In general, I agree with you - we *must* be unambiguous, using formal > references to that work of other bodies that we base ours on, if indeed we > choose to do this. > > As for alphabetic constraints, XSD does give us the ability to do pattern > constraints called regular expressions , so I think we could do what you > suggest, but a simple enumeration datatype will get us to the same place. I > don't think parsers yet support the regular expression stuff, although they > might. ASN.1 has a standard regular expression notation based on the one from XSD with minor corrections and two others in common use. But there is probably little tool support for this feature (outside of Paul Thorpe's :-) and regular expressions are nasty to look at and easy to get rong. I think I've only used one in all the standards I've written: DNSName ::= VisibleString (SIZE(1..MAX)) (PATTERN [A-Za-z0-9 .-]* ) Not something that should ever be inflicted on a business person (or children and small animals for that matter). > As for validation, you do have a good point - few users ever support all of > the codes in a long code lists. But the validation issue depends on > something else. My mental picture of how SMEs will use this stuff has a > lower bound, which is that they view business documents in a browser, based > on a hosted application that can do only two simple things: (1) parse the > document against the schemas; and (2) run it through an XSL or CSS > stylesheet to produce a display form compatible with today's web-browser > technology. Ah. I have a slightly different vision. I see here, rather than generalized UBL documents formed from XML markup under girded with some sort of schema for validation purposes, more tightly defined messages in small protocols. Subsets if you will extracted from the bigger pool of UBL generality. I see bank customers making purchases through agreed to common business interfaces on wireless phones. I see RFIDs in the supply chain beaconing, I'm an invoice for your purchase order #56789 . So I see a need for minimizing code space on the device and bits on the line during transfer. Rather than on the fly negotiation between business partners as to the characteristics of the business forms that they will use, I see large corporations and government entities dictating the form and use of specific UBL instances to their partners and clients - use this if you intend to get paid. And I see processing and security requirements associated with these messages, not just some markup tags with strong typing. This is what I mean by protocol. > There are several companies - mine among them - that offer this type of > low-level, hosted functionality, and it is generally seen as the basic > replacement for FAX-based processes used by the EDI VANs, called Rip & > Read . These applications - because they are generic, XML-based applications > - typically do not offer detailed functionality about the mappings between > sets of codes that are common in more fully automated EDI implementations. > > Because of this, I feel that being able to validate code lists with generic > XSD parsers is very important. So is limiting, to the extent practical, the > sets of enumerated values that people use to express semantics within UBL. Agree. But I would see the ability to cull these list for a given instance of UBL document as an important document construction feature, similar to the need to order the fields and include or exclude some optional generalized document features. As to transfer syntax, security and schemas, maybe what I ultimately need is not UBL, but a derivative or version of UBL that is mobile capable. M-UBL, or MUBL - I'm liking the sound of that nmemonic. So maybe what I'm after here is out of scope for this TC. Phil > Cheers, > > Arofan > >