[
Lists Home |
Date Index |
Thread Index
]
It depends on your public claims. If you claim to meet the standard by
saying that, you imply you do. If you don't, you have to look at the
possible implications of false claims. Keep in mind what a normative
citation implies: it is a caveat vendor system and you must take the
measures to protect consumers of your products. If your citation is
informative and does not claim you comply, you created a caveat emptor
system and it is the consumer of products of your system that has to
take measures to protect themselves.
If you make the claim, you may be required to offer proof. If you
cannot, you may be responsible for any damages such as lost time, lost
opportunities, etc.
The web is by architectural design, a caveat emptor system. In this
case, you are the buyer. You have to decide and publish what acts you
take to protect your consumer and you may be obligated by the contracts
you sign. That is standard practice in many businesses that offer
products or services. Read the fine print.
len
From: Fraser Goffin [mailto:goffinf@googlemail.com]
Ken,
it is interesting to see how some of the rules for how a data standard
must be used are enforced explicitly in the technical artefacts
available to implementers, whereas others form part of specification
or description of usage rules (NDR). Do you (UBL) always prefer the
former if it is possible ?
I face some similar challenging questions from colleagues about
whether it is important to be able to demonstrate compliance to a
[public] standard through validation checks, or whether it is more
important to be able to consume messages and do business regardless of
whether standards are being complied with or not ?
This question just keeps coming back. Shall we accept messages which
contain everything WE might need to process the requested business
(i.e. we only check that it meets OUR requirements which may mean that
it does not always explicitly meet a [public] standard), and ignore
everything else (i.e. not even bother this stuff to check whether it
is compliant to any standard).
Fraser.
On 23/05/06, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
> At 2006-05-23 15:57 +0100, Fraser Goffin wrote:
> >I realise this has been a bit painful so I'll try not to prolong
this,
>
> It is my fault, Fraser, in my haste I mistyped:
>
> >but for my benefit :-
> >
> >> <xs:complexType name="extension">
> >> <xs:sequence>
> >> <xs:any namespace="##other" processContents="skip"
> >> minOccurs="0" maxOccurs="unbounded"/>
> >> </xs:sequence>
> >> </xs:complexType>
>
> In fact it has to be:
>
> <xs:complexType name="extension">
> <xs:sequence>
> <xs:any namespace="##any" processContents="skip"
> minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:complexType>
>
> >I appreciate that you have processContents='skip' and therefore from
> >an XSD validating parser perspective that content will (must) not be
> >validated (but you will or may be validating it elsewhere right),
>
> I'm hoping to find a W3C Schema pure way of restricting the above to
> include an extension namespace specific to a country or industry
sector.
>
> >but
> >doesn't the complexType still act as a sort of specification what the
> >allowable content is (at least to a reader who may not have yet
gotten
> >to a description of the layered validation approach that you are
> >promoting), and in this case specifically dis-allows content that has
> >no namespace affiliation as the immediate child of the extension
> >element ?
>
> That was my mistake ... I meant to do ##other and copied the wrong
fragment.
>
> >I guess this may be what you want though so, in that case does this
:-
>
> No ... I believe because of the W3C Schema restriction that I cannot
> exclude more than one namespace (I have at least four to exclude), I
> have to solve this issue on another layer.
>
> >>and make it a layered business rule that UBL-namespaced constructs
> >>(of the four namespaces) are not allowed as immediate children of
the
> >>UBL extension point based on your earlier comment:
> >
> >also need to state that the UBL extension MUST also *not * contain an
> >immediate child that has no namespace affiliation (or are you
> >proposing that so long as its not UBL namespaced content you don't
> >care).
>
> That won't apply when I improve my copy/paste skills.
>
> Below is an illustration of what I need that works in ISO/IEC 19757-2
> RELAX-NG ... this is what I would have to be able to do in W3C Schema
> to enforce this without a layer.
>
> Thanks for spotting that mistake of mine, Fraser.
>
> . . . . . . . Ken
>
> Z:\data\kendata\dev\nvdl\ublext>type excl.rnc
> namespace a = "urn:x-a"
> namespace b = "urn:x-b"
> namespace c = "urn:x-c"
> namespace d = "urn:x-d"
>
> start = element x
> {
> element * - ( a:* | b:* | c:* | d:* )
> {
> attribute * - ( a:* | b:* | c:* | d:* ) { text }*,
> any
> }*
> }
>
> any = ( text | element * { attribute * { text }*, any } )*
>
> # end
> Z:\data\kendata\dev\nvdl\ublext>type excl1.xml
> <?xml version="1.0" encoding="US-ASCII"?>
> <x>
> <a xmlns="urn:x-a">hello</a>
> <e/>
> <b xmlns="urn:x-b">hello</b>
> <f xmlns="urn:x-f">hello</f>
> <c xmlns="urn:x-c">hello</c>
> </x>
> Z:\data\kendata\dev\nvdl\ublext>jing -c excl.rnc excl1.xml
> Z:\data\kendata\dev\nvdl\ublext\excl1.xml:3: error: element "a" from
> namespace "
> urn:x-a" not allowed in this context
> Z:\data\kendata\dev\nvdl\ublext\excl1.xml:5: error: element "b" from
> namespace "
> urn:x-b" not allowed in this context
> Z:\data\kendata\dev\nvdl\ublext\excl1.xml:7: error: element "c" from
> namespace "
> urn:x-c" not allowed in this context
>
> Z:\data\kendata\dev\nvdl\ublext>type excl2.xml
> <?xml version="1.0" encoding="US-ASCII"?>
> <x>
> <e/>
> <f xmlns="urn:x-f">hello</f>
> </x>
> Z:\data\kendata\dev\nvdl\ublext>jing -c excl.rnc excl2.xml
>
> Z:\data\kendata\dev\nvdl\ublext>
>
>
> --
> Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
> Also for XSL-FO/XSLT training: Minneapolis, MN 2006-07-31/08-04
> Also for XML/XSLT/XSL-FO/UBL training: Varo,Denmark 06-09-25/10-06
> World-wide corporate, govt. & user group UBL, XSL, & XML training.
> G. Ken Holman mailto:gkholman@CraneSoftwrights.com
> Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/
> Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
> Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/u/bc
> Legal business disclaimers: http://www.CraneSoftwrights.com/legal
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>
|
