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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl] Re: Summary: How others handle minor version URIs


XSLT keeps the namespace the same but maintains version info in a 
revision attribute (Group 2b).  This distinguishes behaviour between 
version 1.0 and 2.0.

XSL-FO 1.1 keeps the namespace the same as 1.0 and *ignores* (from 
what I can tell) any revision details.  There appears to be no 
distinction of the revised vocabulary from a vocabulary 
perspective.  An XSL-FO engine either recognizes the new vocabulary 
and implements it, or doesn't and errors out.  It happens I'm not on 
the XSL-FO committee so I can't comment to the reasoning, but I will 
contact someone I know on the committee and ask.

In my personal work I change the namespace for minor versions (1a) 
... no need to add that to the list, but my opinion is that a new 
issue of the vocabulary needs to distinguish to processing 
applications that it is not the same as a previous vocabulary.  A 
processing application being told it is the same could end up missing 
additions or misinterpreting additions or minor changes, and wouldn't 
have any foundation for justifying improper behaviour.  Whereas if a 
processing application is *obliged* to be touched in order to address 
a new namespace, then the application is compelled to be changed to 
address the changes.  Yes, this is a tremendous burden on processing 
applications, but there are techniques one could employ to mitigate 
the effort of upgrading.

What's more important:  making the processing application changes 
optional (by not changing the namespace) or making the data explicit 
in its changes (by changing the namespace?

Do we tell users of UBL that they have to stop using 1.0 once 2.0 is 
published?  Or if a 2.1 is published could users still be "allowed" 
to use 2.0?  If we aren't deprecating older versions of the standard, 
then a person with a 2.0 processing application could defer 
implementing 2.1 changes to the application if they were allowed to 
continue using 2.0 versions of the data.

I hope this helps.

. . . . . . Ken

At 2005-11-02 05:27 -0800, jon.bosak@sun.com wrote:
>==================================================================
>
>Group 1a: Changes the namespace for minor versions
>
>    RosettaNet (electronics)
>    MDDL and FpML (financial)
>
>Group 1b: Changes the namespace for minor versions, but not with
>    good results
>
>    Grants.gov (government grants)
>    SEMATECH (manufacturing)
>
>Group 2a: Keeps the namespace the same for minor versions
>
>    OAGIS (automotive and aerospace)
>    XHTML (WWW)
>    SVG (vector graphics)
>    Most (if not all) of the other W3C XML schemas
>
>Group 2b: Keeps the namespace the same, but maintains version info
>    in a revision attribute
>
>    STAR (automotive)


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