Comment on 1.6 of 26300

[Patrick Durusau]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Makoto,

On 07/20/2013 05:41 AM, MURATA Makoto wrote:
> Since reviewers of the ODF JIS are tough, I need help from you
> guys.
> 

That is a tough one!

Some thoughts below.

> 1.6 of 26300 (as corrected and amended by CORs and an AMD), has a
> para shown below:
> 
> In addition, ODF processors shall ignore all element children
> ([RNG] section 5, Data Model) of ODF-defined elements that are
> strings consisting entirely of whitespace characters and which do 
> not satisfy a pattern of the ODF schema definition for the
> element.
> 
> First, what is an "ODF processor"?  It is never defnied.
> 

Typo: Should read: "ODF processing"

> Second, what is "element children" as defined in RELAX NG?  The 
> only term I can find is "an  ordered  sequence  of  zero  or more
> children;  each  child  is  either  an  element  or  a non-empty
> string;  the sequence never contains two consecutive strings".
> 

Yes and the text (in ODF) goes on to say:

*****
of ODF-defined elements that are strings consisting entirely of
whitespace characters and which do not satisfy a pattern of the ODF
schema definition for the element.
*****

In "the ordered sequence of zero or more children" (RelaxNG) "of
ODF-defined elements that are strings consisting entirely of
whitespace characters and which do not satisfy a pattern of the ODF
schema definition for the element." (ODF)

Taking element children to be strings of whitespace characters and
that do not satisfy a pattern of the ODF schema for the definition of
the element, they are ignored.

Inartful to say the very least. I don't remember any deliberate
whitespace strings but I may be mistaken.

> Third, but technically most importantly, "do not satisfy a pattern"
> is at least misleadnig.  If it is reworded as "do not match a
> pattern", it would be technically correct.   But it continues to be
> very misleading, since readers are required to tell the difference
> between "week match" and "match" in RELAX NG.  Wait.  We can 
> consider matching only for a sequence.  Not for a string in a 
> sequence.
> 

I read the text as requiring a match against the ODF schema.

Isn't it the definition in the ODF schema that controls whether a weak
match or match is required?

If that is true, then why does the text need to say more than:

1) string consisting entirely of whitespace characters, and

2) does not satisfy a pattern of the ODF schema definition for the
element?

"match" a pattern would be better but I don't find it unclear in the
context of markup practice. What else could "satisfy" mean?

It may not be worth the effort at this point but I would strike the
paragraph in question. It is trying to be overly clever about the
whitespace issue.

XML whitespace processing or defined exceptions is much clearer.

Hope you are having a great weekend!

Patrick

> Regards, Makoto _______________________________________________ 
> sc34wg6 mailing list sc34wg6 at vse.cz 
> http://mailman.vse.cz/mailman/listinfo/sc34wg6
> 

- -- 
Patrick Durusau
patrick at durusau.net
Technical Advisory Board, OASIS (TAB)
Former Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR6qWtAAoJEAudyeI2QFGoiGAQALlEWbDPy/800XB1uKK32XPD
rEuumbJ0YPFRDaz33nS+Q2GuvvaK0//5ruC7YDK0tHiL+Wk8VfhEWY2vwZ3y29Ji
6iPA0m+d+2D111ONgKqsjoFRcp4YPPEL+ttM6Ns6BjrQ0XC1lbc+eFa0eRjgNGs4
FAV9nJcM98UC22ijUiaT+KmZAW5vBmBq070A+zLV6j79jm/JAy/UysXOc3UAFMMc
qbS1el4LQF+VZhpSU6/LQ/fmMASwmk4HMEYLGCt+71xRWgO+zz65wfHsPhfDar1D
y/q7wvga72OYrRAKoMlgw6jnhyT/3bD3LrQZ8LZgrNYbHcUVDwRLe4wxgE4UWWEu
TwCmB7ySb9lIi3f/nkxz7PW3hOIdlp9tcnMHkMEbG1muj5XXwg0SUrTKXSLsOWYh
LjiA3xTw9SBwY+G/3fxzbxjnDWDx9mKF9j4JYmk8mcSzhTeo0SOcYGlcecAoMaMW
phm8t+erjI6u70HETwWXeqy6neUjseZI50tK+Pyj6cs3CzCgumrvlCHKFyJz/dmK
oH0MhdcNDalWHnwSBj2DEEIpw/jBNFv/G8Nq3kuwdfE5sko6rEI92/1VHmzOArpE
hQI4vWPyjyCIM6knBAB+ni1SrrC5/qAVaWOVDTWveSSvLjftXSJDQXnYbfehgBp9
Tggeg0CiBDN7sZbwo4P3
=XgXX
-----END PGP SIGNATURE-----