Re: SV: [ubl] Suggestions for an UBL ExtensibleContent area

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

At 2006-02-27 13:59 +0100, Bryan  Rasmussen wrote:
> >In my role as Secretariat Manager for SC34 I've helped the authors
> >marshal the evolution of the above into the standardized
> >Namespace-based Validation Dispatching Language (NVDL) ISO/IEC
> >19757-4 - part 4 of Document Schema Definition Languages (DSDL):
>
> >   http://www.jtc1sc34.org/repository/0694c.htm
>
>excellent news! I had no idea it was up to a draft yet, I thought it was only
>under discussion.

Not only is it up to and past a draft, it is in the FDIS stage 50.20:

   http://www.jtc1sc34.org/document/secretariat_temp.html#matrix

... which means that the technical changes are now done, new 
editorial changes *might* be considered (though a number have already 
gone directly to ITTF for incorporation; it might be too late), and 
ITTF is about to publish the finalized IS.  I think you can consider it final.

> >I have shared with others that I think NVDL would be the best basis
> >for the customization of UBL using namespaces so have pointed them in
> >this direction.
>I'm not averse to this idea, but I think it would be problematic for others
>here.

Ah, good point.

I am of the opinion that UBL instances are not artifacts to be edited 
by people (though of course they can be), but artifacts created by 
programs that can do whatever arbitrary namespace mixing we dictate 
and can validate with the technologies we choose.

To keep UBL instances human editable, which will of course be 
necessary for Joe and Jane User who don't have UBL-aware accounting 
systems, I suppose we will need to consider constraining ourselves to 
tools such as schema-aware authoring tools that might not implement 
the international standards we need.

Hey, I think this situation gives yet more credence to the input 
specifications!  If we can specify in the input specifications how to 
accommodate document- and line-level extensions through namespaces, 
then we *can* use NVRL on the back end and an input tool like OOo 
with ODF on the front end and not be constrained by *authoring 
validation* that doesn't comply with the international standards we 
are working with.

*Then* Joe and Jane User can use tools like OOo/ODF to create UBL 
instances, and validate them with our processes, without having a 
deficient authoring tool in the way.

> >My gut feel is that using NVDL we would probably not need an explicit
> >area for extensible content as the entire instance would be
> >extensible
>yes, but then we would need to define how we were going to deal with
>extensibility if NVDL were our extensibility mechanism. I suppose that would
>then require that everyone sent the document through NVDL processor first.

Yes, but that is (I believe) all within the mindset of working with 
NVDL and solving precisely this problem.  As I said, my work on code 
lists and HISC has prevented me from following up on this, but I have 
this gut feeling that NVDL *is* the answer to unlimited, sector-based 
(or even trading partner-based) customization and validation of UBL 
with any and all extensions they need ... all formally expressible in 
trading partner agreements.

> >  Explicitly creating
> >such a section might lead to the impression that extensions could
> >only be added in that section.
>I think though that if one had an area set aside for extensions, via use of
>xsd:any, that one could use NVDL is one wanted to handle these things, or
>other methods.

Yes, I suppose you are right ... though it seems to me to be 
kowtowing to deficient authoring tools and I'm not fond of making 
information design decisions based on constraints of a tool set that 
doesn't implement available international standards.

> >>), and application usage (transformation). This is more the kind of
> >>thing that should be moved to HISC if ExtensibleContent was accepted.
>
> >I'm not confident that validation issues belong in HISC.  The code
> >list value validation work I'm doing is in a task group of UBL, not of HISC.
>
>Probably right, I was thinking in the context of HISC because the examples I
>was working on were getting very into various possible implementation
>strategies.

Sure, and as above I think I now see where you are going ... with an 
HISC input specification that accommodates arbitrary extensions 
through non-UBL namespaces anywhere in the document, we end up with 
instance creation tools that bypass the need for finding a standalone 
authoring tool that implements international standards.

At the same time we can explore NVDL in the UBL context and propose 
to those UBL committee members looking at contextualization and 
customization its use and demonstrate how this international standard 
can help them finalize an infinitely-extensible framework for UBL, 
and how to formally express the extensions in a form suitable for use 
in trading partner agreements.

So little time .....

. . . . . . . . . . Ken

p.s. Makoto Murata (the editor of NVDL) has posted publicly about 
available implementations, though I don't know of a recent status of these:

  http://lists.w3.org/Archives/Public/public-schemata-users/2005Oct/0001.html


--
Upcoming XSLT/XSL-FO hands-on courses: Washington,DC 2006-03-13/17
World-wide on-site corporate, govt. & user group XML/XSL 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