OASIS Business Document Exchange (BDXR) TC

Dear all


Please find below the agenda for our call Wednesday, April 27, 2016 at 1700 CET:


http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160427T17&p1=48


AGENDA:


1) BDE 1.1 CSPRD 01 public review


https://lists.oasis-open.org/archives/bdxr-comment/201604/msg00001.html
https://lists.oasis-open.org/archives/bdxr-comment/201604/msg00002.html


2) SMP 1.0 CSPRD 02 public review


Some anticipated comments for the SMP 1.0 CSPRD 02 (yet to be published):


- Section 3.3, why must the encoding of XML content be treated as case sensitive?
- Section 2.4.6, case sensitivity of Document Identifiers;
- Section 2.4.7, case sensitivity of Participant Identifiers.


3) Meeting schedule during public reviews


4) Any other business


CALL INFO:


1.  Please join my meeting.
https://www4.gotomeeting.com/join/806072703


2.  Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.


Australia: +61 (0) 2 8014 4935
Austria: +43 (0) 7 2088 1402
Belgium: +32 (0) 38 08 1856
Canada: +1 (647) 724-3550
Denmark: +45 (0) 69 91 88 64
Finland: +358 (0) 942 41 5780
France: +33 (0) 182 880 458
Germany: +49 (0) 898 7806 6467
Ireland: +353 (0) 14 845 978
Italy: +39 0 553 98 95 67
Netherlands: +31 (0) 208 080 381
New Zealand: +64 (0) 9 909 7888
Norway: +47 21 03 58 98
Spain: +34 955 32 0845
Sweden: +46 (0) 313 613 557
Switzerland: +41 (0) 435 0167 08
United Kingdom: +44 (0) 207 151 1851
United States: +1 (215) 383-1010
Access Code: 806-072-703
Audio PIN: Shown after joining the meeting


Meeting ID: 806-072-703

For discussion tomorrow I have this observation to make regarding the anticipated comments. At 2016-04-26 17:00 +0000, Kenneth Bengtsson wrote: Some anticipated comments for the SMP 1.0 CSPRD 02 (yet to be published): - Section 3.3, why must the encoding of XML content be treated as case sensitive? - Section 2.4.6, case sensitivity of Document Identifiers; - Section 2.4.7, case sensitivity of Participant Identifiers. I think the precedent is set in the XML specification where IDREF, IDREFS, ENTITY and ENTITIES attribute content values are case-sensitive. The values are name tokens and the name tokens must be matched exactly. In SGML days it was confusing because it was up to the SGML Declaration (implicit or explicit) to dictate whether name values were or were not case sensitive. On the XML committee it was discussed that this was a level of complexity that took one away from keeping XML simple. Processing and simple assumptions are just easier in XML if one never expects case-insensitive values. It may put a burden on the creator of XML, but the burden of the implementer and the receiver of XML was considered more important than that of the creator in this regard. And in many ways it is just easier for everyone if one never considers case sensitivity and the data is prima-facie what it is without having to interpret it. We wouldn't want one user to say "hey, I thought this was case sensitive" while the trading partner disputes it saying "no, I meant it to be case insensitive this time around". If we stick to case sensitivity in lock-step with XML then the same principle is being applied to both the markup and the data. I realize this is contrary to sections 2.4.6 and 2.4.7, but I hadn't considered the question until posed in the agenda so I hadn't thought about it. An identifier resolution service can choose to be case insensitive and a user's case-sensitive value will work. But it doesn't go the other way around: if an identifier resolution service (which may already exist) is case sensitive and the user thinks the identifier is case insensitive, incorrect values won't be resolved. Thinking about it further, for consideration to add to the SMP, the DOCTYPE external identifier, that is explicit in SGML using "PUBLIC" and is implicit in XML as adjacent to the SYSTEM identifier, matches with case sensitivity but also has a normalization process: https://www.w3.org/TR/2008/REC-xml-20081126/#sec-external-ent "Before a match is attempted, all strings of white space in the public identifier MUST be normalized to single space characters (#x20), and leading and trailing white space MUST be removed." But, then, going back to the identifier resolution service, such may deal with space normalization differently. So it might be risky to presume the normalization. Perhaps we could rely solely on a principle that specifying information shall be constrained but interpreting information may be relaxed. We accept all information as prima-facie what was meant by the author of the values, without normalization and without case sensitivity, and it is up to the services accepting the authored values to assess those values as being conformant, equivalent or even acceptable. We take a hands-off approach stating that zero processing is attempted or implied on any content values from SMP's perspective. As for 3.3, I'm going to be contrary again because the last sentence in 3.3 states the pseudo-attribute is case sensitive but the XML specification states that it SHOULD (their emphasis) be case insensitive: https://www.w3.org/TR/2008/REC-xml-20081126/#charencoding "XML processors SHOULD match character encoding names in a case-insensitive way" This happens to be the only value in XML that is case-insensitive. So "UTF-8" is equivalent to "utf-8" in the XML declaration encoding pseudo attribute: <?xml version="1.0" encoding="utf-8"?> ... but the XML declaration is a directive to the XML processor and not a directive to the user, so it is an outlier from other considerations related to information exchange that are case sensitive. These are interesting discussion points. Chat with everyone tomorrow! . . . . . . . Ken -- Check our site for free XML, XSLT, XSL-FO and UBL developer resources Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/o/ G Ken Holman _ _ _ _ _ _ _ _ _ _ mailto:gkholman@CraneSoftwrights.com Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts Legal business disclaimers: _ _ http://www.CraneSoftwrights.com/legal --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus