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
PPlease consider the environment before
printing this email.
|