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


Help: OASIS Mailing Lists Help | MarkMail Help



   Still banging on about extensibility and validation

[ Lists Home | Date Index | Thread Index ]
  • To: "G. Ken Holman" <gkholman@cranesoftwrights.com>
  • Subject: Still banging on about extensibility and validation
  • From: "Fraser Goffin" <goffinf@googlemail.com>
  • Date: Wed, 3 May 2006 18:28:51 +0100
  • Cc: xml-dev@lists.xml.org, ubl-dev@lists.oasis-open.org
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=lA6mWXG98+0+DfpdVUGe3Pnz3qVItkfgs8ZVgNgVHFXwkhEz2nkp2G8BIdvWN/L8iRSzZ0NtloLNGXWfLYteChLKfi91syIQLtBQ08+QLLJXMCDoEU7Ojb4wnRra7zZGwSwZZmVXEBM0ix0MXQ2nxWz14FRuB6ooTawcuYhDSuE=


a while back you made this interesting observation as part of a larger
conversation about message validation :-

>There are some who hold with a traditional view that the entire
instance *has a >model*, rather than the different view that sets of
labeled information found in an >instance *each have their own model*.
 And those sets are identified >unambiguously through the use of
namespace-rich labels.

>Accommodating "the entire XML instance has a model" is, I believe,
more >difficult, time consuming and frustrating than accommodating
"each set of >information found in an XML instance has its own model".

I really want to believe this (in the practical sense of it being
implementable - now) but there are a few pieces missing from my
understanding which are still troubling me, perhaps you (and others)
can help me out (the recent UBL SBS discussions are also surfacing
some really interesting commentary).

Anyway, as you had mentioned to me earlier wrt UBL code list value
validation, the validation processing *must* first test that a message
is compliant to the structural model (i.e. schema - maybe) before
value-based validation is attempted. I think the reason was/is to
confirm that the expected locations for values are present ?

Also, that UBL schema do *not* use the xs:any or xs:anyAttribute
wildcard mechanisms for extensibility, and in one sense UBL does not
support structural extensibility by trading partners (although
restriction is). This may be not entirely accurate so 'flame away'. It
may also be a bit unfair of me to put this sort of question to you
directly since you have already said you're really involved in the
code list stuff for UBL rather than the general schema work - so apols
for that :-)

So, this got me thinking about how, on the one hand we want to enable
trading partners to not be constrained in terms of any additional
'private' information items they may want to exchange, whilst at the
same time benefit from the broader reach of standards compliance.

If structural conformance is demonstrated by validating message
instances to UBL schema (I mean actual XSDs - for the moment), then
does that mean that :-

a. there is no possibility for trading partners to 'insert' any
private data into a UBL specified content model (as foreign namespaced
items) even if that context make the most sense, since the message
would then be schema invalid ?

b. if the approach is to validate aspects of the message rather than
the message as a whole, what does that mean in terms of a message that
is a composite of a number of a business entity based schema, doesn't
the context of where these individual parts exist in the overall
message typically lend as much to validation as the individual part
itself ?

c. if vocabularies are best developed in a way which allows
information items that are not part of its specification to be 'safely
ignored' (this has been a bit of a theme that has been coming through
recently), then is that really saying that traditional methods of
validating messages (i.e. validating parsers which load up XSDs) won't
really work, we need to move to validation via positional/context
based rules (XPath) ?

d. what about NVDL, (or possibly CAM and/or other methods that are
being talked about).




News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS