Revised text for OPC
MURATA Makoto
eb2m-mrt at asahi-net.or.jp
Wed Jun 24 08:27:49 CEST 2015
Caroline,
Thank you for your careful review again. In London, we studied your
comments carefully, although some of your comments need further
work.
2015-06-09 6:06 GMT+09:00 Arms, Caroline <caar at loc.gov>:
> I promised that I would comment on Murata-san’s latest rewrite of the text
> related to media/content types.
>
> I chose to ignore my earlier comments and approach it again as a new
> reader. So there may be some repetition of points I made before that
> Murata-san argued against. Most of the changes look fine.
>
>
>
> All page numbers relate to OPC WD1 DSig-JH2 and C2MRev.docx as I see it
> but automated changes relating to renumbering in Clause 4 resulted in added
> pages in my copy.
>
>
>
> General issues:
>
>
>
> 1. Inconsistent capitalization for Media Types, Media Types Stream, and
> Media Types Stream Markup. This is a problem throughout. The question is
> what capitalization choices SHOULD be made given that the name of the
> stream is [/[Content_Types].xml]
>
Now, we use "media type" and "the Media Type stream" except in titles, part
property name, and RFC titles.
The list of all occurrences of "media type" is shown at the end of this
mail. "Growth Hint" and
"Media Type" as part property names are also capitalized.
>
> Some clause/subclause headings are not capitalized where they should be.
> I find the use of "Media Types stream" in the narrative slightly confusing
> given that it does not match the stream name. I might prefer "media types
> stream" except in headings. I suggest the group as a whole discuss this
> issue in London.
>
>
>
Capitalization of headings is left to final editing work after the
technical content
is mature.
> 2. How early should we indicate that the "media types stream" is called
> [/[Content_Types].xml]
>
> Currently it is not explicitly stated as text until a table in 9.3.1 and
> in the narrative in 9.3.7. However, "ContentType" shows up in diagrams
> 9.2.3.3. I strongly believe that the stream's name should be mentioned
> informatively earlier than 9.3. My preference would be to add a note to
> the definition of "media type stream" in Clause 4. Alternatively (or
> additionally), add a mention in 9.2.3.2.
>
>
>
Participants of the London meeting do not want to mention
[Content_Types].xml in earlier clauses. This is because this file is
very specific to the ZIP physical package model. Media type
information does not always require a particular file. Even if a
particular file is needed, the file name is not required to be
[Content_Types].xml.
But we added
This clause specifies an abstract model for a package. The requirements for
mapping
these concepts to a physical format, including specifically to ZIP files,
are given in §9.
and
This clause specifies the requirements for mapping the abstract package
model
concepts in §8 to a physical format, including specifically to ZIP files as
described in §9.3.
at the beginning of Clauses 8 and 9, respectively.
> 3. I think we have to use different phrases for the relationship of media
> types to 2046 and 7231. The current text uses "as defined in RFC xxxx" for
> both. Careful readers will see that as an inconsistency. My suggestion is
> to use "using the syntax provided in RFC 7231 3.1.1.1". Note that this
> clause in RFC 7231 refers to RFC 2046, which is useful. Or we might refer
> to Appendix D which also connects OWS (optional white space as included in
> the BNF in 3.1.1.1) to its definition in RFC 7230.
>
>
Now, we use " using the syntax defined in RFC 7231 3.1.1.1"
>
>
> 4. I suspect that Murata-san's changes do not take into account what I
> believe to be an automated relationship between requirements in the text
> and those in Annex G. I would like to emphasize that the separate list of
> requirements is likely to be very useful to folks doing validation of OPC
> packages, for example in the workflow for ingest into a preservation
> repository.
>
>
>
We plan to drop Annex G. It hampers our editing work. No other parts
have such lists of requirements.
Detailed issues:
>
>
>
> Clause 2. Conformance (p. 2)
>
> I suggest we pick a different conformance example (used to show how
> requirements are indicated in the text) to raising the issue about the
> stream that is called [/[Content_Types].xml] but now described by the
> phrase "media types stream." Perhaps use one of the XML Usage requirements
> in 8.2.5. Several of these requirements seem self-explanatory.
>
Not done yet.
>
>
> Clause 3. Normative References (p. 3)
>
> Just noting that RFC 2616 is still referenced in 8.2.3. However, I
> believe that is in a section that Murata-san hopes to delete.
>
Yes, we have deleted the section.
>
>
> Clause 4. Terms and Definitions (p. 5)
>
> I see no reason for upper case in the term here. Change "specially" to
> "special"
>
>
>
We deleted the definition of "Media Type stream". It is rather a provision.
My preference would be to add a note to indicate that the stream is called
> [/[Content_Types].xml] when using a ZIP-based package as described in
> clause 9.
>
Again we do not want to mention this file name in Clauses 1 thru 8.
>
>
> Clause 8. Package Model
>
>
>
> 8.2.3 (p.17)
>
>
>
> I suggest a slight rewording of Murata-san's added text. This also needs
> to be assigned a requirement number.
>
>
>
> "This specification uses MIME media types as defined in RFC 2046 to
> identify the type of content stored in parts. Each part shall have a media
> type (e.g., application/xml) which may have a set of parameters."
>
First, we tried to avoid normative definitions of what is already defined
in MIME RFCs.
As a result, this subclause has much less text then before. I will send a
revised text
very soon.
>
> Would it be more appropriate to use as an example a media type/subtype
> combination that appears in RFC 2046?
>
>
>
> With all the changes, I am unable to figure out exactly which paragraphs
> Murata-san wishes to delete. Looking at in my copy of Word it looks as
> though the proposal includes deleting what seem to be significant
> requirements, e.g., requirement M1.15. I see no problem in deleting the
> syntax presentation if others agree that it is covered adequately in cited
> RFCs.
>
>
>
> However, since RFC 2046 does not provide full BNF for the media type and I
> believe the syntax for a media type should be specified in Clause 8 and not
> only in Clause 9, I would like to see an RFC that does supply the BNF cited
> here too. M1.13 (here, but possibly in the proposed deletion) is the
> syntax requirement for mediatypes. Murata-san did modify the text for M1.13
> in Annex G to refer to RFC 7231.
>
RFC 2046 provides a conceptual definition of media types. RFC 7231
provides one possible syntax for specifying
media types. Thus, we think that 8.2.3 should not reference RFC 7231. We
think that 9.2.3 is the right place.
>
>
> I'll leave it to the BNF and regex experts to thrash out what really needs
> to be in this Clause 8 section. RFC 7231 doesn't get mentioned until
> Clause 9.
>
Yes, this is intentional. RFC 7231 shouldn't get mentioned until Clause 9.
>
>
> 8.2.5 (p. 18)
>
> There might usefully be a pointer to Annex C for the schemas for the "XML
> Content" this subclause relates to, perhaps in the [Note] in the first para.
>
Again, the schemas provide syntax. Thus, it should not be referenced from
Clause 8.
>
>
> 8.3.5 (p. 23)
>
> [M7.3] doesn't seem to exist any more. [not to do with media/content type
> -- just noticed in passing, since an apparent reference to a requirement
> rather than a subclause seemed odd.]
>
We defer editing work of [Mx,x:]. I would like to delete all of them.
>
>
> 8.5.4 third para (p. 29)
>
> may have missing space after mediatype
>
Yes. Done.
>
> Clause 9. Physical package.
>
>
>
> Note: If M1.13 is not in Clause 8, an equivalent requirement certainly
> needs to be added to the main text in clause 9 and refer to RFC 7231.
>
RFC 7231 is referenced in 9.2.3.2.3 and 9.2.3.2.4. We intend to
reformulate requirements on
producers/consumers as requirements on data, thus dropping M1.13.
>
> 9.2.3.2 (p. 34)
>
> I suggest rewording
>
> "For all other physical package formats, the package implementer should
> include an XML stream, known as the Media Types stream, in the package.
> [S2.2] The Media Types stream shall not be mapped to a part by the package
> implementer. [M2.1] This stream is therefore not URI-addressable. However,
> it can be interleaved in the physical package using the same mechanisms
> used for interleaving parts."
>
> to
>
> "For all other physical package formats, the package implementer should
> include an XML stream, described in this specification as the Media Types
> stream, in the package. [S2.2] The Media Types stream shall not be mapped
> to a part by the package implementer. [M2.1] This stream is therefore not
> URI-addressable. However, it can be interleaved in the physical package
> using the same mechanisms used for interleaving parts."
>
We adopted the following.
For all other physical package formats, the package should include an XML
stream called the Media Types stream. [S2.2] The Media Types stream shall
not be mapped to a part by the package implementer. [M2.1] This stream is
therefore not URI-addressable. However, it can be interleaved in the
physical package using the same mechanisms used for interleaving parts.
>
>
> If people are against adding a note to the definition of "media types
> stream", could we insert an example here that gives the
> /[Content_Types].xml name as an example for a stream in a ZIP Archive as
> described in Clause 9.3.? That would partly explain the ContentType
> attributes appearing in the tables below. Otherwise perhaps we need a
> reference to Annex C for the schema for the Media Types Stream.
>
Again, we think that 9.3 is the right place for introducing the file name
[Content_Types].xml.
>
>
>
>
> 9.2.3.3 (starts at p. 35)
>
> Suggest changing each use of "as defined in RFC 7231" to "using the syntax
> provided in RFC 7231 3.1.1.1". See general issue 3.
>
Done.
>
>
>
>
> 9.3.7 (p.45)
>
> Murata-san is proposing deletion of two paragraphs, one of which is
> requirement M3.10. Perhaps need to apply number M3.10 to the new
> paragraph above.
>
>
>
> I’ve attached a text file with (almost) the same content. A just fixed a
> character set problem for [ and ] -- presumably generated when moving a
> text file from the Mac.
>
>
>
> I hope this will be useful at the meeting in London. I am going to be
> sailing for a month starting this weekend and will not be checking my
> Library of Congress e-mail while away.
>
>
>
> Have a good time in London.
>
>
>
> Caroline
>
>
>
149 : Removed the allowance for media type to be an empty
string, as t
149 : s this conflicts with the definition of media type in RFC 2046 and
the existin
175 : map logical item name(s) mapped to the Media Type s stream in a
ZIP archive to
189 : ternet Mail Extensions (MIME) Part Two: Media Type s, The Internet
Society, N.
206 : d in accordance with RFC?3986. The term media type is used in
accordance with
230 : l1 \n 26partstream of bytes with a MIME media type and associated
common prope
311 : are named and related. Parts have MIME media type s and are
uniquely identifie
334 : Media type The type of
content stored
336 : The package implementer shall require a media type and the format
designer sha
336 : d the format designer shall specify the media type . [M1.2] Growth
Hint A sug
371 : Media type s Each part
shall have a me
372 : Each part shall have a media type , as defined in
RFC 2046, to
372 : in that part, consisting of a top-level media type and a subtype,
optionally q
373 : ht restrict the usage of parameters for media type s. [O1.2] Media
types for p
374 : Media type s for parts
defined in this
532 : g part in ways that are specific to the media type of the part;
that is, in ar
532 : om consumers that do not understand the media type s of the parts
containing su
537 : The media type of the
Relationships part i
598 : form to this naming convention have the media type for a
Relationships part. [
655 : atterns and mechanisms for storing part media type s. This Open
Packaging speci
660 : oblems. [Example: Associating arbitrary media type s with parts and
supporting
673 : Part media type Identifies the
kind of con
675 : ide a physical mapping for each part’s media type . [M2.2] Part
contents Stor
682 : Mapping Media Type s to Parts
Introduction Th
684 : apping with a mechanism for associating media type s with parts.
[M2.3] Some p
685 : have a native mechanism for associating media type s with parts.
[Example: The
685 : he header of a MIME entity associates a media type with that MIME
entity. end
685 : ld use the native mechanism to map part media type s to parts.
[S2.1] For all
686 : should include an XML stream called the Media Type s stream. [S2.2]
The Media T
686 : lled the Media Types stream. [S2.2] The Media Type s stream shall
not be mapped
687 : Media Type s Stream Markup
Introductio
689 : The content of the Media Type s stream shall
conform to th
690 : The Media Type s stream
contains XML with a
690 : gs from the extensions of part names to media type s. Override
elements specify
690 : media types. Override elements specify media type s on parts that
are not cove
691 : (§ REF _Ref310242801 \r \h 8.5.2), the Media Type s stream shall
specify either
696 : of Default and Override elements in the Media Type s stream is not
significant.
701 : package implementer can define Default media type mappings even
though no par
707 : The root element of the Media Type s stream.
Default Element
730 : A media type specified using
the syntax
730 : ed in RFC 7231 §3.1.1.1. Indicates the media type of any matching
parts (unles
730 : The package implementer shall require a media type in a Default
element and th
730 : d the format designer shall specify the media type . [M2.6]
annotation Define
732 : gs from the extensions of part names to media type s. Override
Element The st
749 : A media type specified using
the syntax
749 : ed in RFC 7231 §3.1.1.1. Indicates the media type of the part
referenced by th
749 : The package implementer shall require a media type and the format
designer sha
749 : d the format designer shall specify the media type in an Override
element. [M2
757 : Specifies media type s on parts that
are not cove
758 : Media Type s Stream Markup
Example [Ex
760 : ding" \n \t 9? SEQ Example \* ARABIC 6. Media Type s stream markup
<Types x
768 : The Types element is a container for media type s to be used
within the pack
769 : e list of parts and their corresponding media type s as defined by
the Media Ty
769 : esponding media types as defined by the Media Type s stream markup
above. Part
771 : Media type
/a/b/sample1.txt text/pla
781 : Setting a Part Media Type in the Media
Types Stream
781 : Setting a Part Media Type in the Media Type s Stream When
adding a new
782 : package implementer shall ensure that a media type for that part
is specified
782 : type for that part is specified in the Media Type s stream; the
package implem
784 : Override element shall be added to the Media Type s stream.
Compare the resul
785 : tributes of the Default elements in the Media Type s stream. The
comparison sha
786 : matching Extension attribute, then the media type of the new part
shall be co
787 : If the media type s match, no
further action i
788 : If the media type s do not match,
a new Overri
788 : Override element shall be added to the Media Type s stream. If
there is no D
789 : Override element shall be added to the Media Type s stream.
Determining a Par
790 : Determining a Part Media Type from the Media
Types Stream
790 : Determining a Part Media Type from the Media Type s Stream To get
the media t
791 : To get the media type of a part, the
package impl
796 : Check the Default elements of the Media Type s stream,
comparing the exte
800 : rawn from other XML-namespaces into the Media Type s stream markup.
[M2.10] Ma
834 : ogical item does not have an associated media type . [O2.7] The
package impleme
877 : Part media type ZIP item
containing the Me
878 : ZIP item containing the Media Type s stream
described in?§ REF
891 : ogical item prefix has no corresponding media type . [M3.5]
Mapping ZIP Item N
908 : Mapping the Media Type s Stream In ZIP
archives, t
909 : In ZIP archives, the Media Type s stream shall
be stored in
910 : map logical item name(s) mapped to the Media Type s stream in a
ZIP archive to
910 : racters "[" and "]" were chosen for the Media Type s stream name
specifically b
1006 : operties part. The Core Properties part media type is defined in
REF _Ref1433
1056 : rtificate parts. Relationship names and media type s relating to
the use of dig
1069 : e certificate may be signed. [O6.6] The media type s of the Digital
Signature C
1079 : query components that specify the part media type as described
in?§ REF _Ref1
1079 : specify in a case-sensitive manner the media type of the
referenced part. [M6
1106 : ences to package parts include the part media type as a query
component. The s
1108 : where value is the media type of the targeted
part. [Not
1112 : In the following example, the media type is
“application/vnd.openxml
1318 : t with the query component matching the media type of the target
part, necessa
1328 : When validating digital signatures, the media type and the digest
contained in
1335 : ference elements includes verifying the media type of the
referenced part and
1335 : dia type of the referenced part and the media type specified in
the reference
2229 : Media Type s Stream
<xs:schema xml
2477 : Media Type s Stream
default namespace
2607 : (normative)Standard Namespaces and Media type s The
namespaces available
2612 : Media Type s stream
http://schemas.ope
2623 : The media type s for the parts
defined in t
2623 : 9361607 \h \* MERGEFORMAT Package-wide media type s Table
STYLEREF \s "Appe
2624 : E? SEQ Table \* ARABIC 2. Package-wide media type s Description
Media type
2626 : Media type Core
Properties part appl
2638 : s and format designers shall not create media type s with
parameters for the pa
2638 : eat the presence of parameters in these media type s as an error.
[M1.22] The
2720 : The package implementer shall require a media type and the format
designer sha
2720 : d the format designer shall specify the media type . REF
_Ref129157037 \r \h
2765 : create and only recognize parts with a media type ; format
designers shall spe
2765 : type; format designers shall specify a media type for each part
included in t
2765 : e for each part included in the format. Media type s for package
parts shall fi
2765 : shall fit the definition and syntax for media type s as specified
in RFC 7231,?
2770 : _14 \h \* MERGEFORMAT The value of the media type is permitted to
be the empt
2771 : Media type s shall not use
linear white
2771 : or between an attribute and its value. Media type s also shall not
have leadin
2771 : age implementers shall create only such media type s and shall
require such med
2771 : such media types and shall require such media type s when
retrieving a part fro
2771 : ormat designers shall specify only such media type s for inclusion
in the forma
2776 : The package implementer shall require a media type that does not
include comme
2776 : he format designer shall specify such a media type . REF
_Ref129157439 \r \h
2807 : s and format designers shall not create media type s with
parameters for the pa
2807 : eat the presence of parameters in these media type s as an error.
REF _Ref143
2842 : form to this naming convention have the media type for a
Relationships part
2877 : ht restrict the usage of parameters for media type s. REF
_Ref140643471 \r \h
2912 : REF m2_1 \h The Media Type s stream shall
not be mapped
2916 : red components package, part name, part media type , and part
contents. REF
2920 : apping with a mechanism for associating media type s with parts.
REF _Ref129
2924 : than relationships parts (§8.5.2), the Media Type s stream shall
specify either
2935 : The package implementer shall require a media type in a Default
element and th
2935 : d the format designer shall specify the media type . REF
_Ref140665453 \r \h
2940 : The package implementer shall require a media type and the format
designer sha
2940 : d the format designer shall specify the media type in an Override
element. RE
2945 : package implementer shall ensure that a media type for that part
is specified
2945 : type for that part is specified in the Media Type s stream; the
package implem
2949 : REF m2_9 \h To get the media type of a part, the
package impl
2953 : rawn from other XML-namespaces into the Media Type s stream markup.
REF _Ref
2990 : A: Only relevant if using the media type mapping
strategy specified
3001 : ave a native mechanism for representing media type s. REF s2_1b
\h \* MERGEF
3001 : uld use the native mechanism to map the media type for a part.
REF _Ref12915
3005 : If no native method of mapping a media type to a part
exists, REF s2_
3005 : d XML stream in the package, called the Media Type s stream REF
_Ref129159669
3026 : A: Only relevant if using the media type mapping
strategy specified
3053 : package implementer can define Default media type mappings even
though no par
3061 : ogical item does not have an associated media type . REF
_Ref112211501 \r \h
3066 : A: Only relevant if using the media type mapping
strategy specified
3095 : ogical item prefix has no corresponding media type . REF
_Ref140683954 \r \h
3117 : _10 \h Package implementers shall store media type data in an
item(s) mapped t
3121 : map logical item name(s) mapped to the Media Type s stream in a
ZIP archive to
3316 : uery components that specifies the part media type as described
in?§12.3.5.7.
3316 : ent that incorrectly specifies the part media type to be an error.
REF _Ref
3321 : th a query component that specifies the media type that matches
the media type
3321 : ecifies the media type that matches the media type of the
referenced part. The
3321 : ignature validation to fail if the part media type compared in a
case-sensitiv
3321 : pared in a case-sensitive manner to the media type specified in
the query comp
3414 : signatures, consumers shall verify the media type and the digest
contained in
C:\Users\makoto\Downloads\OPC pre-WD2 London.docx (matched:23 score:41.8)
149 : Removed the allowance for media type to be an empty
string, as t
149 : s this conflicts with the definition of media type in RFC 2046 and
the existin
190 : ternet Mail Extensions (MIME) Part Two: Media Type s, The Internet
Society, N.
208 : d in accordance with RFC?3986. The term media type is used in
accordance with
315 : nd related. Parts have content typeMIME media type s and are
uniquely identifie
377 : This specification uses MIME media type s as defined in
RFC 2046 to
377 : stored in part. Each part shall have a media type , as defined in
RFC 2046, to
377 : in that part, consisting of a top-level media type and a subtype,
such as appl
378 : tent typeMedia types define a top-level media type , a subtype, and
an optional
378 : shall fit the definition and syntax for media type s as specified
in RFC 2616,?
700 : have a native mechanism for associating media type s with
partsrepresenting con
700 : he header of a MIME entity associates a media type with that MIME
entity. end
701 : ally named an XML stream , known as the Media Type s stream, in the
package, .c
701 : am, in the package, .called the Content Media Type s stream. [S2.2]
The Content
704 : Media Type s stream
markupIntroduction
705 : The content of the Media Type s stream shall
conform to th
797 : Setting the a Content TypePart Media Type of a Partin the
Media Types
797 : ent TypePart Media Type of a Partin the Media Type s Stream When
adding a new
806 : ypea Part Media tType of a Partfrom the Media Type s Stream To get
the content
893 : Part content media type ZIP item(s)
containing XML
894 : r each part according to the patternthe Media Type s stream
described in?§ REF
925 : In ZIP archives, the Media Type s stream shall
be stored in
2922 : shall fit the definition and syntax for media type s as specified
in RFC 261672
Regards,
Makoto
>
>
>
>
>
>
> 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 [mailto:eb2mmrt at gmail.com] *On Behalf Of *MURATA
> Makoto
> *Sent:* Sunday, May 10, 2015 5:23 AM
> *To:* SC34
> *Subject:* Revised text for OPC
>
>
>
> Folks,
>
>
>
> In the draft minutes, I was tasked to "make a further update to the
>
> draft text to incorporate references to RFC 2045 and/or RFC 2046 for
>
> the concepts of media type and subtype and to RFC 7231 (replacing the
>
> reference to RFC 2616) for the syntactic definition (ABNF) in clause 8
>
> Package Model." I tried to do the task.
>
>
>
> Later, Caroline sent some useful comments from a more careful look at
>
> the latest draft. I accepted most of her comments and even proposed
>
> text (thank you, Caroline!). My disposition is shown in an attached
>
> document ("MediaTypeCheck...").
>
>
>
> Please find my rewrite. Although I already sent a rewrite of the
>
> Content Type regular expression (see the threead "Rewriting the regexp
>
> for @ContentType in opc-contentTypes.xsd"), I have not incorporated
>
> my rewrite yet.
>
>
>
> Regards,
>
> Makoto
>
>
>
>
>
--
Praying for the victims of the Japan Tohoku earthquake
Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20150624/67cb281c/attachment-0001.html>
-------------- next part --------------
Standardization side
Regulatsion side
Earlier directives, July
New regulation
Two parts: (1) identification and (2) trust serices
Developing technical
Aplicaable to signatures and electronic seals
99% equally to fields and transactions
Legal requirement
XAdES
Regulartion 910 214: eIDAS
Not made mandatory.
Some recommended standard is the new XAdES.
The new XAdES is the one required.
2016: one year switch over period
Standardiation
Over a few years, consultation.
Adopted to align with the regulation.
Based on feedbacks, we have received.
Approved document , now editorial update,
New weeks
Public download area of ETSI
In two ways
One: draft EN -> all member countries of EU
Two: technical specification of ETSI, available in a few weeks
EN 319 162-1aa
-------------- next part --------------
AHL: Teleconference on 6/26th
Issue for synchronization
1. Two Schemas: I will open an issue
Link to the changes doc
2. Create a schematron schema
3. Fill out the document
4. Review the specification
-------------- next part --------------
1. すでに調べてある系列を、変換結果から分類する。
問題は、まだ足りない分類結果があることだが、それは気にしないことにする。
分類を保存するような削減のしかたを調べる。保存できる削減があるのなら、これで解空間を間引く。
これが出来れば、高速化できる。もし、dをすべて削除できれば15から10に減る。
grep -v dをすればdをすべて削除した結果がわかる。
11手をすべて探求することは出来ている。
11手までであまり使われていない手があれば、それは除いてみよう。
11手までで使われている手順をリストする。
11手までであまり使われていない二手順があれば、それは除いてみよう。
11手までであまり使われていない三手順があれば、それは除いてみよう。
18*18が二手
18*18*18が三手
-------------- next part --------------
XAdES
Does eIDAS encourage the use of the upcoming XAdES only or both the
existing and upcoming XAdES?
Are baseline profiles most important?
How will the schema be reorganized?
Further comments possible?
Extensions
Should an applicaion program ignore foreign parts older than standard parts?
Should an application program always preserve foreign parts? Or,
should it discard them when they modify standard parts significantly?
Should Part 1 require that SML applications should modify
the content of extLst when columns or rows are added or deleted?
More information about the sc34wg4
mailing list