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


One of the 3 ACORD schemas also uses the version in the namespace for
the reasons Ken states. The PCS schema uses this methodology, the Life
spec plans to change for each major revision, not sure what the RLC
schema plans to do.

PCS which is the schema I'm most involved with went this direction
because it is the only methodology that tools will recognize the change
in versions. Any other approach is going to be specialized by ACORD. I
basically co-opts the namespace and said it is the equivalent of a
public identifier for this schema, because I think it is important to
know which version of the schema you are using and I want the tools to
recognize that change. 

Now maybe this is a topic for a TC in OASIS to come up with a cross
industry standard for handling this issue.

..dan

> -----Original Message-----
> From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
> Sent: Wednesday, November 02, 2005 7:59 AM
> To: ubl@lists.oasis-open.org
> Subject: Re: [ubl] Re: Summary: How others handle minor version URIs
Snip

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

snip


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