Re: [ubl] Proposed addition to 2.1 documented constraints

ubl message

Subject: Re: [ubl] Proposed addition to 2.1 documented constraints - no schema location hints

From: JAVEST by Roberto Cisternino <roberto@javest.com>

To: "G. Ken Holman" <gkholman@CraneSoftwrights.com>

Date: Sat, 17 Oct 2009 11:21:01 +0200

I am pretty sure that systems where an URI resolver is used (even based on XML Catalogs) are able to resolve either namespaces and, at a certain level, file paths.

Common URI Resolvers like the one available from Normal Walsh (SUN) are going to solve most of these issues.

Anyway I noted that there could be systems that could erroneously promote the XSI "hint" to a "mandatory pointer", and this could
generate:
1) rejecting documents containing schemaLocations, or
2) or rejecting documents in which the schemaLocation does not match the intended schema document.

Most common XML processors do not assign any precedence to XSI hints as the schema lookup mechanisms imposed by the parser application should take precedence (properties, resolvers, ...).

We could just mention in UBL that XSI where used is just a hint for the parser, or even we could suggest to provide just a relative path or just the schema filename.

We can't provide a full URI resolving guide but we should suggest that the UBL xsd and other validation resources should be discovered by checking the UBL version, customization and profile information, not only the namespace URI.

Into this case an XSI schemaLocation could be seen as a short-cut to discover the right Schemas (the name at least).

Of course into eBusiness partnerships there is usually an agreement for each document exchange, and a precise channel for I/O where any validation resource and mechanism can be predefined (and expected).

In some way I still think the "bad" XSI could provide some help on simple implementations, but it is my opinion.

Hope this helps,

Ciao

---
G. Ken Holman ha scritto:

7.0.1.0.2.20091016150858.026610a8@wheresmymailserver.com" type="cite">At 2009-10-16 20:01 +0100, Stephen Green wrote:

I'm not sure these are necessarily issues of UBL per se.
If UBL starts to include such as normative requirements
it looks like meddling or 'nannying' the implementers.

Point taken ... but we already started this nannying, particularly for interoperability.

It would be OK if within the mandate (charter?) of UBL's
scope but I don't think UBL's charter offically should
include providing any 'best practice' guidelines for XML
general use for data interchange.

Then what was the reason for including 6.2 Character Encoding? For interoperability, because all XML processors are required to support UTF-8 but not required to support other encodings, UBL has stated that for data interchange a UBL document shall be in UTF-8.

Though most XML processors support other encodings, an XML processor may not support other encodings, but this isn't an issue for UBL because UBL states that UTF-8 shall be used.

Interestingly, I see both "MUST" and "SHOULD" for the same issue in the actual documentation for 6.2, but that's another issue for editing and NDR review:

http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html#d0e3610

... and given that an absent encoding= implies UTF-8 or UTF-16 an XML declaration without encoding= satisfies the requirement. Or is UTF-16 meant to be expressly prohibited?

Doing so can surely
be done by the same people that produce UBL, as a kind
of 'lessons learned' about use of XML for data interchange

As I'm doing in my classroom.

but not as normative statements of requirements to be
part of UBL specs since it is broader than UBL's scope.

Then for xsi:* we don't have to say anything. It was my personal opinion this was in scope.

Is there anything special about UBL that means it needs
a special implementation of XML?

Precisely the other way around ... UBL requires UTF-8 so that every implementation of UBL doesn't have any concerns about character set.

My intention was that by prohibiting the interchange of xsi:* then any model expression of the UBL vocabulary will work without needing to know about non-XML concepts like xsi:* that come from W3C Schema.

What is the difference
between sending and receiving UBL messages and using
XML in other ways. If it's the sending and receiving itself
(interchange) then that is for a wider audience than UBL
interchange and it should not be that just because it is
UBL being used for that interchange then these perceived
best practices MUST be implemented, whether one agrees
with them or not.

Granted ... but I perceived a constraint like 6.2 to be precisely an issue brought to the UBL user's attention that directly impacts on *interchange* issues in case trading partners are not using the same XML processors.

But as I said, I'll drop this and leave it for the classroom only ... I just wanted it discussed in case anyone else felt as I do about this issue. We've already broached interoperability of interchanged UBL documents, and this came to mind.

Thanks everyone, for the discussion!

. . . . . . . . Ken

--
Upcoming: hands-on code list, UBL, XSLT, XQuery and XSL-FO classes
in Copenhagen Denmark and Washington DC USA, October/November 2009
Interested in other classes? http://www.CraneSoftwrights.com/m/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/m/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/m/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Nessun virus nel messaggio in arrivo.
Controllato da AVG - www.avg.com 
Versione: 8.5.421 / Database dei virus: 270.14.20/2440 -  Data di rilascio: 10/16/09 06:32:00

  

JAVEST by Roberto Cisternino

* Document Engineering Services Ltd. - Alliance Member * UBL Italian Localization SubCommittee (ITLSC), co-Chair * UBL Online Community editorial board member (ubl.xml.org) * Italian UBL Advisor

Roberto Cisternino

mobile: +39 328 2148123
skype: roberto.cisternino.ubl-itlsc
[UBL Technical Committee]	http://www.oasis-open.org/committees/ubl
[UBL Online Community]	http://ubl.xml.org
[UBL International Conferences]	http://www.ublconference.org
[UBL Italian Localization Subcommittee]	http://www.oasis-open.org/committees/ubl-itlsc
[Iniziativa divulgativa UBL Italia]	http://www.ubl-italia.org

PPlease consider the environment before printing this email.