MCE -- treatment of examples in document

[Arms, Caroline]

After today's call I have extracted these points on examples from my message of yesterday.

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.

Page 15 in draft .91.  8.5
   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.

Page 22.  10.2
    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.

   Caroline

Caroline Arms
Library of Congress Contractor
Co-compiler of Sustainability of Digital Formats resource
http://www.digitalpreservation.gov/formats/

** Views expressed are personal and not necessarily those of the institution **
________________________________________
From: eb2mmrt at gmail.com [eb2mmrt at gmail.com] On Behalf Of MURATA Makoto [eb2m-mrt at asahi-net.or.jp]
Sent: Tuesday, August 13, 2013 5:11 AM
To: SC34
Subject: Proposed text for Clause 9

Dear colleagues,

Here is a proposed rewrite of Clause 9.  It is based
on Francis' wording but has been modified and further
expanded by two examples.  Thanks. > Francis.

Regards,
Makoto
-----------------------------------------------------------------------------

9. Extension elements defined by a markup specification (informative)

A markup specification that uses Markup Compatibility elements and
attributes to allow extensions in namespaces other than those defined by the
markup specification may also define one or more specific extension elements
in the namespaces that it defines. [Note: If the markup specification
includes a schema, any extension elements would normally be constrained by
the schema to occur only in specific markup contexts. end note].

If an MCE processor is configured to recognise extension elements, it
preserves them together with their attributes and contents.  See
Clause 9 for details.


[Example:

https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/ExtensionElements/example1.xml

In this example, the e1:foo element contains the unknown:foo element.
Suppose that a markup configuration contains an expanded name
("http://www.example.com/e1", "foo") and that an application
configuration does not contain "http://www.example.com/unknown".
Then, the element e1:foo is an application-defined extension element.
Although the unknown:foo element does not belong to an understood or
ignorable namespace, the MCE processor preserves it and does not
report any errors. end example]

[Example:

https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/ExtensionElements/example2.xml

In this example, Markup Compatibility elements and attributes occur
within the extensionElement element, which is the only child of the
root element example.  Suppose that a markup configuration contains an
expanded name ("http://www.example.com/e1", "extensionElement").
Then, the MCE processor preserves the extensionElement element.
Therefore, MCE elements and attributes within it, namely mce:Ignorable="i1",
mce:ProcessContent="i1:bar1", mce:MustUnderstand="e1",
mce:AlternateConent, mce:Choice, and mce:Fallback, appear in the output
document.  end example]

After receiving the output of an MCE processor, application programs
may further invoke an MCE processor to handle Markup Compatibility
elements and attributes within extension elements.