SV: [ubl] IND7 UBLVersionID

["Bryan Rasmussen" <BRS@itst.dk>]

To clarify my argument here:

Suppose the target namespace of the schema was incorrect and did not follow
the UBL NDR defined rules for how a target namespace must be defined. The
schema will thus never work. I suppose that we would all feel this was a
non-meaningful change and change it immediately. Despite the fact that from a
validation standpoint this would be a very significant change indeed.

This is because we know what the namespace is supposed to be exactly due to
the NDR and any variation from that is not meaningful, is the equivalent of a
spelling error. 

In the case of UBLVersionID the change proposed is, from a validation
standpoint, much less important than a namespace change and in this case we
know what the cardinality is supposed to be exactly due to the NDR and I
would argue that any variation from that is not meaningful, is in fact the
equivalent of a spelling error. 

I realize that this sounds counterintuitive but I hope that consideration of
the argument will lead to agreement. 

Cheers,
Bryan Rasmussen


-----Oprindelig meddelelse-----
Fra: Bryan Rasmussen [mailto:BRS@itst.dk]
Sendt: 31. juli 2006 09:42
Til: jon.bosak@sun.com; tmcgrath@portcomm.com.au
Cc: ubl@lists.oasis-open.org
Emne: SV: [ubl] IND7 UBLVersionID


Hi,

The documentation I was thinking of was specifically the NDR, to quote from
NDR
http://www.oasis-open.org/committees/download.php/19218/NDR-2006-07-19.pdf :

"UBL version information will also be captured in instances of UBL document
schemas
1189 via a ubl:UBLVersion element.
1190 [VER15] Every UBL document schema MUST include a required element named
1191 "UBLVersionID" as the first child of its root element. This element MUST
1192 have a default value that matches the value of the xsd:version attribute
of
1193 its containing schema.Every UBL document schema MUST include a required
1194 element named "UBLVersion" as the first child of its root element. This
1195 element MUST have a default value that matches the value of the
1196 xsd:version attribute of its containing schema."

I'm supposing that the NDR is not considered to be Informative, but is at a
higher level than schemas. Otherwise why have an NDR for schemas (is it
because one can then read the NDR to understand how Schemas are structured?
but I think the NDR could be quite a bit shorter then. ) It is of course true
that we will do things to bring both into agreement with each other, but I
wasn't thinking Schemas overrode the NDR but rather the opposite. 

Anyway, it is for this reason I think we should be able to argue it is a
minor change.

By the way, I noticed that changes to the NDR were carried with in this
version. Is that the way it is supposed to be or has the metadata not been
rinsed from the document, or perhaps changes were carried with in converting
from another format? 







-----Oprindelig meddelelse-----
Fra: jon.bosak@sun.com [mailto:jon.bosak@sun.com]
Sendt: 30. juli 2006 16:07
Til: tmcgrath@portcomm.com.au; Bryan Rasmussen
Emne: Re: [ubl] IND7 UBLVersionID


(off the list)

[tim:]

| what we now need to decide is whether the changing of UBLVersionID
| to minOccurs=1 constitutes a significant change.  If so then we
| may have to let this pass for UBL 2.0 (and make a note in the NDRs
| to this effect) and fix it for 2.1.

I'm not sure we can let this go.  It was essential to the concept
of UBLVersionID that it be required.  And the change would be
substantive because it would affect software.

I'd be glad to be convinced otherwise.

| I would suppose that it is not a significant change because it is
| a change to bring the schemas in line with documentation that can
| be considered to be at a higher level.

But we've taken the position that the documentation is informative
and that we can make any changes we like to bring it into
alignment with the schemas.  We can't now take the position that
the documentation is normative and can drive the schemas.

There were other reasons to suspect that we might need one more
revision cycle; maybe we'd better start planning for it.

Jon

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php