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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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. 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. 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
but not as normative statements of requirements to be
part of UBL specs since it is broader than UBL's scope.
Is there anything special about UBL that means it needs
a special implementation of XML? 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.

Best regards
Stephen D Green

2009/10/16 G. Ken Holman <gkholman@cranesoftwrights.com>:
> At 2009-10-16 19:48 +0200, JAVEST by Roberto Cisternino wrote:
>> I am not aware of the requirement to use RELAX-NG, however the W3C XML
>> Schema is a normative syntax for UBL.
> No, it is the normative schema.  It is a set of constraints.  The choice of
> having done so has magically added support for these non-XML attributes for
> every document that uses it.
>> Are we going to provide other normative syntaxes ?
> No, I expect not.
> But nor do we prohibit users from using any XML tools on UBL data either.
>  If someone wants to use RELAX-NG on their XML then they have to know that
> because we do not prohibit xsi:* for platform portability that they have to
> now accommodate that trading partners may be sending them documents with
> these rogue attributes.
> My intent on suggesting this is to promote interoperability by recommending
> that UBL documents meant for interchange not include platform-specific
> attributes introduced by W3C Schema that are not part of the UBL vocabulary.
>> G. Ken Holman ha scritto:
>>> But I sincerely believe platform dependencies have no role in an
>>> interchange document and can only introduce problems for recipients.
>> I agree it is not related to the interchange of data, but within simple
>> systems where a sophisticated xml catalog resolver is not available the xsi
>> schemaLocation could provide precious information expecially for instances
>> where the namespace URI do not provide full information about the XML Schema
>> version/customization/profile.
> But your precious location information that you use in your UBL document on
> your system may generate errors on my system if (for the same reasons you
> cite) I'm obliged to use an XSD tool that respects the xsi:* values.
>  Without the prohibition then you send me your instance with your attribute
> value and I now have to edit the document I receive from you before I can
> work with it.
> With the prohibition then I don't see any of your private location
> information that is meaningless to my system.
>> Instead, a simple system could be resolving the XML Schema location
>> internally by just retrieving the schema name from the xsi:schemaLocation.
>>  In fact the schema name could be the original name used for that kind of
>> customization or profile.
> That might be what it is on your system, but if my schemas are in different
> directories or on different disks, then it isn't going to work.
>> So if the schema name is "UBL-Invoice-2.0-Watusi-Tall-1.0.xsd"  the
>> receiver could match this file locally on their system using just the name
>> and ignoring the original path of the sender.
> How is the original path ignored?  If I have to go into the file and hack
> that attribute to make it work, then I'm not working with the instance as
> received.  And that isn't scalable if I'm getting thousands of documents.
>> I know this seems to be stupid or crazy, but implementations are very
>> similar to my example around the world... :)
> Fine, then, I'm not supposed to worry about this issue.  I see proper use of
> XML catalogues in tools like Oxygen, but many years ago when I first looked
> at XML Spy (I haven't looked at it in a long time), this attribute was
> crucial for the correct behaviour of the editor.
> If a recipient has none of the problems I've anticipated when opening a file
> from a sender that has a pointer to the sender's internal system, then my
> worries are addressed.
> Thanks, Roberto, for bringing this to my attention.  We have nothing, then,
> to put into the documentation.  Nevertheless, I'll still be including it in
> my training material as I personally can think of the situations I've
> described where the attribute gets in the way (and it isn't part of the UBL
> vocabulary).
> . . . . . . . . . . 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/o/i/
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
> 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/o/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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]