[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: SV: [ubl-dev] UBL- just how reliable are XSD based syntax checks?
Bryan, Good comments on namespaces - this definately mirrors my experiences - and nice links and examples. +1 here. What CAM does in fix conflicting default namespace declarations - is not change the XML itself - but creates a better reference structure with the conflicts resolved there. This then acts as a "roadmap" and override to ensure accurate processing of XPath as the XML content itself is traversed. Basically humans can glance at the XML and intuitively "know" what namespace the default belongs to at what point in the heirarchy - but of course java code - cannot make that call so easily - so jaxen especially - needs fully qualified content - you cannot mix and match default and non-default namespaces. Also we've seen instances where the same default namespace in-line declaration is made in multiple places - this "works" but its not correct - they should be unique. Paradoxically the worst XML I've seen is the one I've had to work with for two years as part of Grants.gov applications! This falls under the category of - if people can mess it up - they will... So - with all this experience - I prefer simple XML if I can get it! But as you say - how to relate this back to the original definitions and vocabulary? The <Reference> section in the CAM template is designed to provide that using UID references to the (UBL) domain vocabulary items. So you don't need the namespace equating. This is a win on multiple levels - including thinner XML payload sizes - faster processing, etc. And also - being able to use non-english localization tagnames / or abbreviations - but equate them exactly to their english equivalents in the standard [now there's a radical concept... ; -)] We still need to do some work here though - we know it can work - but CEFACT is still visiting on the XSD for CCTS in registry - once that is definitive - then we'll be able move forward on defining the formal normative specification for this. Cheers, DW "The way to be is to do" - Confucius (551-472 B.C.) -------- Original Message -------- Subject: SV: [ubl-dev] UBL- just how reliable are XSD based syntax checks? From: "Bryan Rasmussen" <BRS@itst.dk> Date: Mon, February 12, 2007 5:21 am To: "David RR Webber (XML)" <david@drrw.info>, "G. Ken Holman" <gkholman@CraneSoftwrights.com> Cc: <ubl-dev@lists.oasis-open.org> >Simple XML without namespaces - like it or not - is a lowest common >denominator, for both tools and people. I know that will be processed >by a simple lightweight XML processor, or import / export feature. I can agree with that, with the note that every XML processor that I know of that will not handle XML Namespaces in a manner the correctness of which I have not had occasion to question (and the only time I ever questioned the handling of an XML namespace by a processor I was wrong anyway) is an XML processor that is does not follow the XML spec by itself. The one that comes to mind offhand is Rebol's built in processor, but I have seen similar processors in various lisp-y languages. This can be useful when you want to write a processor for RSS or similar standards with 'unimportatn' data, but other than that I don't think it is useful. Note, I have heard that SAP has problems with long namespaces. > UBL fortunately is not in that bucket - but plenty of other XML is - >with conflicting default namespaces, inline namespaces and duplicate >and invalid namespace declarations. hmm, I can think of some XSLT processor errors in the way they handle namespaces, but this is dependent on the XSL-T spec not on namespaces. What you are saying sounds like basic irritating aspects of namespace scoping, are there processors that mismanage these things? I mean it sounds to me you are complaining about stuff like this <?xml version="1.0"?> <!-- initially, the default namespace is "books" --> <book xmlns='urn:loc.gov:books' xmlns:isbn='urn:ISBN:0-395-36341-6'> <title>Cheaper by the Dozen</title> <isbn:number>1568491379</isbn:number> <notes> <!-- make HTML the default namespace for some commentary --> <p xmlns='http://www.w3.org/1999/xhtml'> This is a <i>funny</i> book! </p> </notes> </book> from the spec. I can see why one might complain but it is what I've always understood and experienced as perfectly allowable. Do you have examples where a processor accepts bad namespaces? This reminds me of Joe English's psychology of namespaces screed some years back: http://lists.xml.org/archives/xml-dev/200204/msg00170.html >CAM is able to read in bad namespaced content and fix it and create >better namespace declarations for you so it processes with XPath >expressions that work correctly. I might find any tool automating namespace changes for me scary. I want to be able to say change all namespaceX to namespaceY then run namespaceY handling. >The fact that CAM can handle that content with or without those >namespaces - interchangably - clearly something that does not interest >you - but may be of convenience to implementers. Well I don't know that I would argue that UBL needs namespaces in the form they are in now, but I think for any large dialect Namespaces are really beneficial, especially if we want to extend the dialect or want others to extend their dialects with ours. Basically I think the complexity of UBL namespaces is dependent on some of the irritating aspects of using XML Schema as a validation language. >Contrary wise - seems that you are OK with using downstream feeds that >collect data that ultimately ends up being packaged in real UBL - as a >convenience - just so long as those downstream feeds are not labelled >as "UBL". I think everyone is okay with that. Cheers, Bryan Rasmussen --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]