[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: SV: [ubl] Suggestions for an UBL ExtensibleContent area
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]