Re: SV: SV: [ubl] Discussion XSD implementation of extensions

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2006-07-13 15:37 +0200, Bryan  Rasmussen wrote:
>Allan just pointed out the UBL rule that one can't have an empty element,
>i.e. element without content or attributes.
>
>With what you're proposing for Streaming purposes one ends up with possible
>empty elements.

Yes, but in the Atlantic meeting that you and 
Allan missed this was raised and the rule was 
changed to allow the extension element to be empty.  Check out:

   http://www.oasis-open.org/committees/document.php?document_id=19124

and you will see ELD7 reads as follows:

   "Empty elements MUST not be declared, except in
    the case of extension, where the 'UBL Extension'
    element is used."

Once the syntax of the UBL Extension element is 
finalized, we'll change the wording to reflect 
ext:ExtensionContent element name.

>Fra: Bryan Rasmussen [mailto:BRS@itst.dk]
>Sendt: 13. juli 2006 14:43
>Til: G. Ken Holman; ubl@lists.oasis-open.org
>Emne: SV: SV: [ubl] Discussion XSD implementation of extensions
>...
>Don't know if it should be allowed to be empty, despite the benefits to
>streaming processing. I don't want things to be done in a particular way to
>benefit one processing model.

But if you turn that argument around, it would be 
a shame to penalize a particular processing model 
by a modeling decision that would be acceptable 
either way to other processing models.

>What do you think the chances are of people outputting extension elements
>that are empty? Without extension content?

In my proposed methodology, there is a 100% chance:

   http://www.oasis-open.org/committees/document.php?document_id=18849

In my processing model I posit that an 
application expecting either no extension or 
optional extension "X" will need to process an 
instance with an extension "Y" to remove the 
extension "Y" such that the end result can be 
validated with the schema that expects optional extension "X".

It was in this discussion paper where I was 
justifying the necessity to remove extension 
namespace elements from instances and still have 
the end result validated against a schema, thus 
requiring the end result of intermediate 
processing to have empty content for that one element.

What I really like now about your reminder for us 
to include extension metadata, is that even after 
removing the extension namespace from the 
instance, the processing application has enough 
information to know that there even was an 
extension in the instance before the instance was 
massaged.  This might help direct workflow 
processes.  With metadata my "X" application can 
now inspect its validated intermediate instance 
and see that there was a "Y" extension present in 
the original instance, but it is dealing with a 
pure "X" set of information items.

>Also I would think that would make it difficult or less optimizable for some
>implementors that might want different handling of extensions or not
>stream-based handling of the format.

I'm sorry I don't understand what you mean by 
that.  Tree-based processing can inspect the 
presence of the extension easily, while 
stream-based processing cannot inspect the 
presence of the extension without waiting until 
it encounters the extension ... or have 
labourious look-ahead issues that could impact performance and maintenance.

But I hope I have convinced you of the 
accommodation of an instance with unexpected 
extensions removed to still be allowed to be 
validated with a schema before application 
processing.  I used the arguments above in the 
Atlantic call, and I feel strongly after an 
analysis of the impact of system design that 
removing the look-ahead issue for stream 
processing should be regarded as removing an 
obstacle to deployment, rather than regarded as 
adding a preferential bias of any kind.  After 
all, tree-based processing doesn't need to worry 
about look-ahead, so let's accommodate 
stream-based processing if we can easily.

Please let me know if this hasn't convinced you.

. . . . . . . . . Ken

--
Registration open for UBL training:    Montr�al, Canada 2006-08-07
Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
Also for UBL/XML/XSLT/XSL-FO training: Varo,Denmark 06-09-25/10-06
World-wide corporate, govt. & user group UBL, XSL, & XML training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal