<div dir="ltr">Caroline,<div><br></div><div>"Markup specification" in MCE is a special term. It includes a set of </div><div>expanded names, which are declarations of application-defined extension</div><div>elements.</div>
<div><br></div><div>Regards,</div><div>Makoto</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/14 Arms, Caroline <span dir="ltr"><<a href="mailto:caar@loc.gov" target="_blank">caar@loc.gov</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Extracted from the message I sent yesterday with primarily editorial suggestions -- my preliminary thoughts on definitions brought up by Murata-san. Note that I wrote these before I understood the ISO policy that requires replaceability in the text, but I don't think that invalidates these suggestions.<br>
<br>
On the call, I suggested that the definitions should be revisited by Murata-san and Francis as they revise sections 7 and 9.<br>
<br>
Markup consumer (and Markup producer)<br>
I agree with Murata-san that "and further conforms to the requirements of a markup specification" is not relevant and should be dropped from the definition of markup consumer. Similarly markup producer definition should probably be adjusted to "tool that can generate a markup document that conforms to a markup specification." That is, it is the document that must conform, not the tool.<br>
<br>
Markup specification<br>
When you look at "markup specification" you suddenly see that this seemingly generic phrase is defined as specific to "this part of ISO/IEC 29500." I would prefer the use of a term that included reference to MCE in some way. That is, if the term really needs to be specified so tightly. Personally, I can see no reason for the limitation to this part of ISO/IEC 29500 -- but someone else need to check that out. In places where the discussion is specific to MCE use, that seems clear to me from the context.<br>
<br>
Caroline<br>
<br>
Caroline Arms<br>
Library of Congress Contractor<br>
Co-compiler of Sustainability of Digital Formats resource<br>
<a href="http://www.digitalpreservation.gov/formats/" target="_blank">http://www.digitalpreservation.gov/formats/</a><br>
<br>
** Views expressed are personal and not necessarily those of the institution **<br>
________________________________________<br>
From: Arms, Caroline<br>
Sent: Tuesday, August 13, 2013 10:55 AM<br>
To: SC34<br>
Subject: MCE -- treatment of examples in document<br>
<br>
After today's call I have extracted these points on examples from my message of yesterday.<br>
<br>
Sections 8 and 10 have examples that are mainly edge cases. More typical examples are in Annex A and could possibly be included in or referenced from the main text. After the technical substance is finalized, it has been agreed that the location/use/cross-referencing of examples needs to be revisited in a holistic fashion. These were the places in which things seemed particularly awkward to me.<br>
<br>
Page 15 in draft .91. 8.5<br>
I think it would be good to have a typical example (i.e. one with Choice and Fallback elements), not just edge cases. Or to refer to Annex A, Example A.5.<br>
<br>
Page 22. 10.2<br>
Example starting on page 22 is essentially two examples in one -- from reading the text. I think it would be clearer to start with the more typical example and follow by the related edge case that the markup chunk represents.<br>
<br>
Caroline<br>
<br>
Caroline Arms<br>
Library of Congress Contractor<br>
Co-compiler of Sustainability of Digital Formats resource<br>
<a href="http://www.digitalpreservation.gov/formats/" target="_blank">http://www.digitalpreservation.gov/formats/</a><br>
<br>
** Views expressed are personal and not necessarily those of the institution **<br>
________________________________________<br>
From: <a href="mailto:eb2mmrt@gmail.com" target="_blank">eb2mmrt@gmail.com</a> [<a href="mailto:eb2mmrt@gmail.com" target="_blank">eb2mmrt@gmail.com</a>] On Behalf Of MURATA Makoto [<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank">eb2m-mrt@asahi-net.or.jp</a>]<br>
Sent: Tuesday, August 13, 2013 5:11 AM<br>
To: SC34<br>
Subject: Proposed text for Clause 9<br>
<br>
Dear colleagues,<br>
<br>
Here is a proposed rewrite of Clause 9. It is based<br>
on Francis' wording but has been modified and further<br>
expanded by two examples. Thanks. > Francis.<br>
<br>
Regards,<br>
Makoto<br>
-----------------------------------------------------------------------------<br>
<br>
9. Extension elements defined by a markup specification (informative)<br>
<br>
A markup specification that uses Markup Compatibility elements and<br>
attributes to allow extensions in namespaces other than those defined by the<br>
markup specification may also define one or more specific extension elements<br>
in the namespaces that it defines. [Note: If the markup specification<br>
includes a schema, any extension elements would normally be constrained by<br>
the schema to occur only in specific markup contexts. end note].<br>
<br>
If an MCE processor is configured to recognise extension elements, it<br>
preserves them together with their attributes and contents. See<br>
Clause 9 for details.<br>
<br>
<br>
[Example:<br>
<br>
<a href="https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/ExtensionElements/example1.xml" target="_blank">https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/ExtensionElements/example1.xml</a><br>
<br>
In this example, the e1:foo element contains the unknown:foo element.<br>
Suppose that a markup configuration contains an expanded name<br>
("<a href="http://www.example.com/e1" target="_blank">http://www.example.com/e1</a>", "foo") and that an application<br>
configuration does not contain "<a href="http://www.example.com/unknown" target="_blank">http://www.example.com/unknown</a>".<br>
Then, the element e1:foo is an application-defined extension element.<br>
Although the unknown:foo element does not belong to an understood or<br>
ignorable namespace, the MCE processor preserves it and does not<br>
report any errors. end example]<br>
<br>
[Example:<br>
<br>
<a href="https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/ExtensionElements/example2.xml" target="_blank">https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/ExtensionElements/example2.xml</a><br>
<br>
In this example, Markup Compatibility elements and attributes occur<br>
within the extensionElement element, which is the only child of the<br>
root element example. Suppose that a markup configuration contains an<br>
expanded name ("<a href="http://www.example.com/e1" target="_blank">http://www.example.com/e1</a>", "extensionElement").<br>
Then, the MCE processor preserves the extensionElement element.<br>
Therefore, MCE elements and attributes within it, namely mce:Ignorable="i1",<br>
mce:ProcessContent="i1:bar1", mce:MustUnderstand="e1",<br>
mce:AlternateConent, mce:Choice, and mce:Fallback, appear in the output<br>
document. end example]<br>
<br>
After receiving the output of an MCE processor, application programs<br>
may further invoke an MCE processor to handle Markup Compatibility<br>
elements and attributes within extension elements.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto
</div></div>