Comment on 1.6 of 26300

[MURATA Makoto]

Patrick,

Thank you for your reply.

>> First, what is an "ODF processor"?  It is never defnied.
>>
>
> Typo: Should read: "ODF processing"

Yes, this is one possible fix, although it is strictly speaking
an undefined term also.  Is this about consumers or
producers?

Moreover, what happens when a consuming
application never throws away whitespace text chunks
that precede or follow element siblings?
They would work fine as long as they do not touch such
text chunks.  Why should we prohibit such applications?
I start to think that the best way to fix this subclause is to
delete it.

>> 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.

"satisfy" is not the right word for the validation of such ordered
sequences against patterns in RELAX NG.  Use either "weak
match" or "match".  They are very different in whitespace
handling.  See 19757-2 and study inference rules for "match"
and "weak match".  Moreover, does this subclause apply to
sequences containing foreign children?  If so, the current text
is very very mistaken.

> 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.

This is not enough.  See above.

>
> 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?

"weak match".

Regards,
Makoto

>
> 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.

I agree.

Regards,
Makoto

> 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-----
> _______________________________________________
> sc34wg6 mailing list
> sc34wg6 at vse.cz
> http://mailman.vse.cz/mailman/listinfo/sc34wg6



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto