MCE -- terms and definitions

[Arms, Caroline]

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.

On the call, I suggested that the definitions should be revisited by Murata-san and Francis as they revise sections 7 and 9.  

Markup consumer (and Markup producer)
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.

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

    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: Arms, Caroline
Sent: Tuesday, August 13, 2013 10:55 AM
To: SC34
Subject: MCE -- treatment of examples in document

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.