[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] UBL- just how reliable are XSD based syntax checks?
At 2007-02-10 12:33 -0700, David RR Webber \(XML\) wrote: >Ken, > >I spotted these statements in the email discussions - that were grouped >together (see below). I'm not sure why you addressed me with this, David, as each and every one of these comments you cite are from Tim, not from me. I focused on interchange of information and the conformance of the document model, *which is what started this discussion*. Your points are disingenuous to the thread I started. >Now - let me postulate that it is entirely possible to create XML >documents - that while they may conform to the UBL schemas exactly - >will cause any UBL-based system to crash and fail if they attempt to >process them I'll let Tim talk to your points, David, if he wishes but I personally will stay focused on this discussion about a tool/technology "providing 100% compatibility with the original UBL schemas" ... sorry, all along I've been talking about the interface between two applications according to a published specification and the normative component of that specification is a set of W3C schemas. I don't care what CAM may or may not be able to do, and I don't know what CAM does or doesn't do, as successful interchange and the challenges you raise are all premised on the information being identified by being properly labeled using a published XML vocabulary that everyone recognizes. Even a CSV file can have data errors and that's the responsibility of other layers and of tools to determine on top of basic interchange using CSV. I didn't bring up that discussion you cite. I brought up my issues against the stated notion that somehow an interchange UBL XML document that doesn't validate against the published XSD schemas because of stripping namespaces at the convenience of a tool or a technology can still be called "UBL". Perhaps the tool is doing so because it is insufficient to the task and cannot handle namespaces or it is incorrectly working with namespace prefixes or default namespaces and not properly with namespace URI strings. While any technology may be interesting to some, if it cannot handle a namespace-qualified XML document as specified by the W3C, then it isn't a fully XML-based tool. If it cannot take an untouched XML document with arbitrary declarations of namespaces and the redefinitions of the default namespace all according to the XML specification, then it isn't a fully XML-based tool. There are tools out there that act this way because they aren't implemented to the full specification of XML and namespaces for whatever reason. Back in the SGML days there were tools that didn't implement all of SGML and users were told to use a simpler version and simple translation and somehow "it is all okay". It is not okay for those people who wished to use the SGML features that were not supported. As I said before, this is a common refrain and we are hearing it again from vendors of XML-based tools that do not handle what is possible in XML, and I felt compelled to bring this up because of new users of XML that have their eye on UBL. Consider that the popular XSLT stylesheet processors have no problems with the proper arbitrary use of namespace URI strings, prefixes and default namespaces, so that means it isn't impossible to implement a fully-XML-based technology. And it was Steve's example and comment that illustrates this premise I've heard from some vendors who have been pushing in the markup world that for some reason *just to be able to use a convenient tool that doesn't properly support XML* that the true XML document needs to be massaged for the tool (not for the user): At 2007-02-09 09:11 -0700, stephen.green@systml.co.uk wrote: >After making a schema as previously mentioned with zero namespaces >(or at most one) and just one schema file I went on to >customise the Catalogue proper UBL schema files too. >... >It does work so far >though and a simple transformation both to and from UBL proper >instances is made possible while allowing validation against a >necessarily simpler schema. Reiterating:- that's a schema with no >more than one namespace and no more than one module/physical file. "necessarily" simpler? Necessarily to what? A tool? Create brand new schema expressions of already-published schemas just to "make it simpler"? It is a disservice to users to put the burden of translation on them if the tool they are using can't handle the UBL instances they receive or need to send. At 2007-02-10 12:33 -0700, David RR Webber \(XML\) wrote: >Conversely then we should note that where the on-the-wire-format in XML >may be simplified to permit easy processing - while at the same time - >via a simple transform mechanism like CAM - will provide 100% >compatiblity with the original UBL schemas - when that check is >introduced into the process as a conformance check. And you are using this "simpler" term too and *that's* where I have a problem, David. That is why I started this thread. It is irresponsible and misleading to a community of new users of XML to somehow imply that if they are using a "simpler" markup version of a UBL document that it is a UBL document. The existence of a "simple" transformation to and from schema-valid UBL and a "simplified" format is irrelevant and misguiding to new users who are being told "this is okay, it is still UBL" ... it isn't UBL and it cannot be used for interchange. The labels of UBL (which are a combination of namespace URI and local name, not prefix and full name) are well-defined for interchange purposes and, therefore, should not be changed. All I'm saying is do what you want to do behind the scenes, and I don't care what tools you use, just don't expose as UBL something that isn't UBL. Don't publish an XML instance using the UBL local names and washed of the proper UBL namespaces and call it "UBL" because it isn't. That is what Stephen was doing and that was why I was trying to help the UBL Dev community by taking from my time to comment. My comments are unrelated to Tim's comments regarding compatibility and the design of custom business objects based on UBL business objects ... I'm focused on improperly purporting a UBL-like instance without namespaces as being UBL. I'll let Tim respond to your comments, David ... I'll stay focused on the issues that I started. . . . . . . . . . . . . Ken -- World-wide corporate, govt. & user group XML, XSL and UBL training RSS feeds: publicly-available developer resources and training G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/u/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]