OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[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]