HTML5.2のdates and timesで先発グレゴリオ暦の紀元前1年と10000年より未来は妥当な値になるのか

HTML

W3CのHTML5.2の2.4.5. Dates and timesと2.4.5.1. Monthsの内容に食い違いがあり0000-01や10000-01が妥当な月の文字列かどうか良く分からないという話

追記

各仕様の内容、HTMLチェッカーによる解釈では以下の通りです

仕様またはチェッカー Month 0000-01 Month 10000-01
HTML 5.2の2.4.5. Dates and times 妥当 (*1) 妥当ではない
HTML 5.2の2.4.5.1. Months 妥当ではない 妥当
HTML Living Standard (*2) の2.3.5.1. Months 妥当ではない 妥当
Ready to check - Nu Html Checker (*3) 妥当ではない (Error: Year cannot be less than 1.) 妥当 (Warning: Year may be mistyped. (*4))
妥当 *1
between the proleptic year 0000, and the year 9999. の記述を0000年を含むと解釈した。含まなければ妥当ではない
HTML Living Standard *2
Last Updated を参照した
Ready to check - Nu Html Checker *3
時点の実装による
Warning: Year may be mistyped. *4
誤記の疑いとして警告が出ているだけで、エラーではない

HTML 5.2の2.4.5.1.、HTML Living Standard、Nu Html Checkerの判定が一致する事、HTML 5.2の2.4.5.のみ異なる判定となりNOTE内の記述であることから、2.4.5.のbetween the proleptic year 0000, and the year 9999.の記述が誤りであろうと考える

また、本記事、本追記を書くにあたり、twitterにて もんど (@momdo_) さんから色々助言をいただいた

改めて感謝を申し上げる

2.4.5. Dates and timesのNoteには以下の記述があります

This specification encodes dates and times according to a common subset of the [ISO8601] standard for dates.

(中略)

Dates are expressed in the proleptic Gregorian calendar between the proleptic year 0000, and the year 9999. Other years cannot be encoded.

Dates and timesは標準日付 [ISO 8601] の共通サブセットに従って日付と時刻をエンコードし、年は先発グレゴリオ暦で0000年から9999年の間であるとされています

紀元0年は存在しませんが、ISO 8601で0000年は先発グレゴリオ暦の紀元前1年とされているので、値としては 0000 から 9999 の間で、範囲は先発グレゴリオ暦紀元前1年から9999年の間と読めます

一方、2.4.5.1. Monthsで定義される妥当な月の文字列は以下の通りです

A string is a valid month string representing a year year and month month if it consists of the following components in the given order:

  1. Four or more ASCII digits, representing year, where year > 0
  2. A U+002D HYPHEN-MINUS character (-)
  3. Two ASCII digits, representing the month month, in the range 1 ≤ month ≤ 12

つまり、年を表す4桁以上のASCII数字で0より大きい数、ハイフン (-)、月を表す2桁のASCII数字で1以上12以下、を連続させたものが妥当な月の文字列となります

上記によればDates and timesのNOTEの記述に関わらず、0000-01は妥当な月を表す文字列ではありません (where year > 0の条件に反する)

一方で、Dates and timesのNOTEでは最大9999-12と読めますが、MonthsではFour or more ASCII digitsとあるので10000-01も妥当な月を表す文字列です

between the proleptic year 0000, and the year 9999. が 0000 と 9999 を含まないと解釈すれば0000-01は妥当でないとして双方の内容が一致しますが、9999については疑問が残ります

個人的な感想としては、Dates and timesのDates are expressed in the proleptic Gregorian calendar between the proleptic year 0000, and the year 9999. Other years cannot be encoded.の記述が単に余計で、NOTEで概要を説明しようとして他の箇所と矛盾する事を書いてしまっただけなのではないかと思うのですが、どうなのでしょうか

ちなみにHTML Living Standard — Last Updated 12 January 2018では2.3.5. Dates and timesのNOTEにbetween the proleptic year 0000, and the year 9999.の記述はないのでこの問題は生じません

その上で2.3.5.1. Monthsの妥当な月の文字列の年の部分の定義はFour or more ASCII digits, representing year, where year > 0となっており、W3CのHTML5.2と同じです

2018年の抱負

Life

この記事は自分向けの記事です

新年あけましてもう10日経ちましたが今年の抱負です

2017年の12月には決めており、前倒しで実行中ですが、blogの更新も再開したことですし表に出して宣言した方が途中で妥協したり投げ出したりしなくて良いだろう、という記事です

もうちょっと頻繁にblogを更新する

日記自体は6年くらい書いているのですが、公開しても構わない内容についてはblogとかで残した方が良いのではないかと昨年末に思って更新を再開しました

具体的な数値目標 (最低毎月1本とか) を定めて義務化すると私の性格だと長続きしないことが分かっているので更新されなくなったら「あ、やる気なくなったんだな」と思ってください

体重を60kgまで落とす

今何kgかというと74kgで、身長は165cmです

外見はそこまで肥満ではなく「そんなに太っているように見えない」とお世辞込みで言っていただけるのですが、つまり内臓脂肪と言う事です

体重計に載ると尿から糖とか蛋白とか嫌な単語が頭をよぎります

痩せろ

HTML5.2の仕様書を一通り読む

先日から始めたHTML5.2の見出し毎の内容を雑にまとめるシリーズが途中経過の成果物になります

昨年末から読み始めており、毎月1章分づつ記事が公開できれば嬉しいのですが、2018年内に終わる見込みが立っていません

兎に角一回読み終わってHTML5.3以降は変更点だけ読んで終わりにする、そんな人に私はなりたい

応用情報技術者試験に合格する

基本情報処理には合格しているのですが2001年のことで、業務で触れないし興味もないことにはとんと疎い状態が17年ほど続いております

そんな状況で身近な非プログラマーの人が昨年の秋期基本情報処理試験に合格しまして、なんの根拠もない私のプライドが危険に晒された為、応用情報処理を受験してみることにしました

まずは春期試験を受けますが、今年の抱負なので秋期試験で合格でもいいや、と年始から逃げを打っておくことにします

HTML5.2の見出し毎の内容を雑にまとめる、1. Introduction

HTML

HTML5.2の見出し毎の内容を雑にまとめる、この記事の序文と Abstract からの続き

1. Introductionから1.11. Suggested readingまで

殆どの部分がThis section is non-normative.である為、他の場所以上にざっくり斜め読み

1. Introduction (導入)
1.1 Background (背景)

This section is non-normative.

もともと学術文書のマークアップ用途だったのが、その後一般化してWebApplicationの記述までするようになったとかなんとか

1.2 Audience (この文書の仮想読者?)

This section is non-normative.

Web技術について全然知らない人はこの仕様読む前にチュートリアルとかやっとけ、特にDOMは知っとけ

1.3 Scope (範囲)

This section is non-normative.

この文書は静的または動的な文書の意味づけの仕様だよ、表現 (presentation) に関する仕様じゃないよ、オンラインの購買システム、検索システム、ゲーム、アドレス帳、コミュニケーションソフト、文書編集ソフト辺りが向いているよ

1.4 History (歴史)

This section is non-normative.

色々あって、HTML Standardの安定版をW3Cのグループが勧告するようにったよ

1.5 Design notes (設計ノート? (基本的な設計思想的な話?))

This section is non-normative.

色々あって一貫性ないし、デファクトスタンダードを取り込んだりしてきたけど、設計思想を説明するよ

1.5.1. Serializability of script execution (スクリプト実行の順次実行性? (このシリアルはパラレルの対義語で「並列処理しない」の意))

This section is non-normative.

Scriptの並列処理は複雑なのでできないようにしとくよ

1.5.2. Compliance with other specifications (他の仕様への準拠)

This section is non-normative.

他の仕様に依存しているけど競合することもあるけど、意図的な時は理由と共に意図的って書いとくよ

1.5.3. Extensibility (拡張性)

This section is non-normative.

意味づけの拡張の為にclass属性とかdata-*属性とかmeta要素とかrel属性とかscript要素とかJavaScriptを活用する方法があるよ

1.6. HTML vs XML Syntax (HTML構文 対 XML構文)

This section is non-normative.

HTML5はHTML構文とXML構文でかけるよ

1.7. Structure of this specification (この仕様の構成)

This section is non-normative.

この仕様の構成

1.7.1. How to read this specification (この仕様の読み方)

この仕様は何度も繰り返し読み返して把握すべきである

あと、HTMLの書き手側 (producers) へ要求する適合要件と、読み手側 (consumers) へ要求する処理方法は独立している

1.7.2. Typographic conventions (表記の規則)

この仕様の定義、要件、説明などのマークアップ例

1.8. Privacy concerns (プライバシーへの憂慮)

This section is non-normative.

一部のHTMLの機能は、利便性を向上させる一方でユーザーのプライバシーを脅かす (ので注意が必要である)

1.9. A quick introduction to HTML (簡易なHTMLの手引き)

This section is non-normative.

HTMLの基本的な構造など

開始タグがあって、終了タグがあって、入れ子にはならなくて、みたいな話

1.9.1. Writing secure applications with HTML (HTMLで安全なアプリケーションを記述する)

This section is non-normative.

HTMLで双方向のサイト (interactive sites) を作成する場合、攻撃者がサイトやユーザーを危険に晒す脆弱性を作りこまないように気を付ける必要がある

  • Not validating user input
  • Cross-site scripting (XSS)
  • SQL injection
  • Cross-site request forgery (CSRF)
  • Clickjacking
1.9.2. Common pitfalls to avoid when using the scripting APIs (スクリプトAPIを利用する時に陥らないようにすべき、よくある穴)

This section is non-normative.

言葉で説明/理解するのが難しいので例示のコードを読むべし

凄く雑に言えば、イベントハンドラの登録タイミングによってはそのイベント完了後かもしれないので、イベントハンドラはそれを起こす要素などと一緒に追加するようにすれば安心、という話

1.9.3. How to catch mistakes when writing HTML: validators and conformance checkers (HTMLを書くときにミスを見つける方法: 検証ツールと適合性チェッカー)

This section is non-normative.

Ready to check - Nu Html Checker 使え

1.10. Conformance requirements for authors (著者に要求する適合条件)

This section is non-normative.

この仕様では妥当でない文書の処理方法についても定義する

ただし、妥当でない文書の処理方法が定義されているからと言って、妥当でない文書を書いていい訳ではない

1.10.1. Presentational markup (外見の為のマークアップ)

This section is non-normative.

以前のHTMLにあった大多数の外見の為の機能 (Presentational features) は不許可になったし、外見の為のマークアップは問題がある

唯一残っているのはstyle要素とstyle属性である

また、以下の要素は媒体から独立するよう再定義された: b, i, hr, s, small, u

1.10.2. Syntax errors (構文違反)

This section is non-normative.

HTMLの構文は様々な問題を避けるために制約が課せられているよ

具体的な内容は本文の具体例を参照すること

1.10.3. Restrictions on content models and on attribute values (コンテンツモデル (要素の内容) と属性値の制限)

This section is non-normative.

言語の構文以外にも、この仕様には要素と属性の指定にも制限が存在するよ

具体的な内容は本文の具体例を参照すること

1.11. Suggested reading (読んどくといいもの)

This section is non-normative.

  • Character Model for the World Wide Web 1.0: Fundamentals [CHARMOD]
  • Unicode Security Considerations [UNICODE-SECURITY]
  • Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20]
  • Authoring Tool Accessibility Guidelines (ATAG) 2.0 [ATAG20]
  • User Agent Accessibility Guidelines (UAAG) 2.0 [UAAG20]
  • HTML Accessibility APIs Mappings 1.0 [html-aam-1.0]

続く

HTML5.2の見出し毎の内容を雑にまとめる、この記事の序文と Abstract

HTML

HTML4.01の頃はHTMLの仕様などを読んでいたが最近ご無沙汰でHTML5とかさっぱり分からなくなっているし、最新版以外のHTMLをすべて廃止しようという動きもある (Proposal to Republish Previous Versions of HTML and XHTML as Obsolete Recommendations (Wide Review until 2017-09-07) from Xueyuan on 2017-08-11 (public-review-announce@w3.org from August 2017) ) こともあり、改めて最新のHTMLの仕様を読んでみることにした

最新のHTMLの仕様というと、WHATWGのLiving StandardとW3CのHTML5.2があるが、Living Standardは読んでいる間に内容が変わりそうなので、HTML5.2を対象と決めた

1回読んで全部理解できるものでもないので、とありえず読んだら章ごとに数行程度の要約や感想を書きつつ取り合えず頭から最後まで読んでみる事にした

この記事にはその記録である

なお、たった一行の要約でさえ多くの誤りが含まれている可能性があるが、予めご了承い頂きたい

HTML5.2 の仕様 を読むにあたり、momdo さん訳のHTML5.1の日本語訳とHTML Standerdの日本語訳を参照させていただいており、深く感謝している

Abstract (概要)

WWWの中核をなすHTMLの5.2だよ、今後ともどんどん更新していくよ

Status of this document (この文書の位置付け)

この文書はHTML5.1を廃止して取って代わるし、将来他の文書に取って代わられるから最新版は https://www.w3.org/TR/(https://www.w3.org/TR/) を見よ

HTML5.2の見出し毎の内容を雑にまとめる、1. Introduction へ続く

バッチファイルからWindows PoweShellの実行ポリシーを設定する

Windows PowerShell

新しいWindows端末でPowerShellを使う場合、最初に実行ポリシィを設定する必要があります

最初に1回だけやればいい話ですが何らかの事情で頻繁に行う人にはやっぱり面倒です

そういう作業はPowerShellで自動化したい所ですが、なにせWindows PowerShellの実行ポリシーですのでWindows (DOS) コマンドのバッチをファイルの出番です

コマンドプロンプト上ではWindows PowerShellのコマンドレットはPowerShellコマンドで実行できます

PowerShell -Command "Set-ExecutionPolicy RemoteSigned -Scope CurrentUser;"

できました

これで終わりだと流石に短いのでもう少し続けます

仮に、Windows PowerShellで端末設定部分を自動化したけれど、そのps1ファイルを実行するのに実行ポリシーを変更したい、そして実行後はWindows PowerShellの実行ポリシーを元に戻したい、とします

この場合先にPowerShell Get-ExecutionPolicyで値を取得しておいて、あとから再設定することになります

ECHO OFF

REM 権限の保存
FOR /F "usebackq" %%i IN (`PowerShell -Command Get-ExecutionPolicy`) DO SET PSEP=%%i

REM 権限の設定
PowerShell -Command "Set-ExecutionPolicy RemoteSigned -Scope CurrentUser;"

REM ps1ファイルのの実行
PowerShell -File "\\nas\Set-EnvironmentInfo.ps1"

REM 権限を戻す
PowerShell -Command "Set-ExecutionPolicy %PSEP% -Scope CurrentUser;"

今回は最終的に実行したいps1ファイルを今回は\\nas\Set-EnvironmentInfo.ps1としています

また、バッチファイル化することを前提に考えているので%は二つ重ねて書いています

なお、設定をRemoteSignedにしていますが、もちろんここは用途に応じて変更してください

そんな感じで

Windows PowerShellのFunction入門 (Paramキィワード、Parameter属性編)

Windows PowerShell

この記事はWindows PowerShellのFunctionのParamキィワードの基本的な説明とParameter属性の話です

値の指定 (AllowNullとか) などは出てきませんので予めご了承ください

PowerShellに名前付きで引数を設定するには、関数名の後ろに "()" で記述する方法と、関数内にParamキィワードで記述する方法の2種類ががあります

いずれの場合も宣言した変数名の$を-に変えたものがパラメータ名になります

Function SampleFunction1 ($InputString) {
    Write-Host $InputString;
}

Function SampleFunction2 {
    Param(
        $InputString
    )
    Write-Host $InputString;
}

PS> SampleFunction1 -InputString "Hello";
Hello
PS> SampleFunction2 -InputString "World";
World
````

上記のどちらの書き方でも結果は同じ為、本記事では以下<code>param</code>キィワードを使う書き方で説明します

---

パラメータは変数宣言と同じように型名を付けて宣言することが出来ます

また、複数の引数を設定する場合、',' 区切りで記述します

Function SampleFunction3 { Param( [String] $InputString1, [String] $InputString2 ) Write-Host (($InputString1, $InputString2) -join ' '); }

PS> SampleFunction3 -InputString1 "Hello" -InputString2 "World"; Hello World ````

パラメータ用の特殊な型としてSwitchがあります

Switchはパラメータとして記述されると$True、なければ$falseになります

Function SampleFunction4 {
    Param(
        [Switch] $Switch1,
        [Switch] $Switch2
    )
    Write-Host (('Switch1 is', $Switch1) -join ' ');
    Write-Host (('Switch2 is', $Switch2) -join ' ');
}

PS> SampleFunction4 -Switch1;
Switch1 is True
Switch2 is False

パラメータにデフォルト値を付けたい場合、$変数名 = デフォルト値の形で記述します

Function SampleFunction5 {
    Param(
        [String] $String = 'Hello World'
    )
    Write-Host ($String);
}

PS> SampleFunction5;
Hello World

各引数には個別にParameter属性を記述することで、必須属性かどうか、パイプラインから値を受け取るかなどの設定を行う事ができます

主なParameter属性のオプションは以下の通りです

HelpMessage
パラメーターの簡単な説明文を String 型で指定。必須パラメーターの入力がない場合に使用されますが、使用方法は実装依存
Mandatory
必須かどうかを Boolean 値で指定
ParameterSetName
パラメーターのセット名を設定します。非常に長くなる為、本記事では割愛します
Position
パラメータ名がない引数の位置 (昇順) をInt型で指定。なお、関数内のすべてのパラメータがPositionを持たない場合、記述順で解釈される
ValueFromPipeline
パイプラインオブジェクトからの入力を受け入れるかどうかを Boolean 型で指定
ValueFromPipelineByPropertyName
同じ名前または同じエイリアスを持つパイプラインオブジェクトのプロパティから、その値を取得するかどうかを Boolean型で指定。ValueFromPipelineByPropertyNameが$trueの場合、ValueFromPipelineを併せて書く必要はない
ValueFromRemainingArguments
バインドされていない (パラメーター名つきなく、位置からも特定できない) 残りの引数を受け入れるかどうかを Boolean型で指定。記述がない場合は $false

以下サンプルコードです

# HelpMessage と Mandatory
Function SampleFunction6{
    Param(
        [Parameter(Mandatory=$true,HelpMessage='年齢を入力してください')]
        [String] $Age;
    )
}

PS> SampleFunction6
コマンド パイプライン位置 1 のコマンドレット SampleFunction6
次のパラメーターに値を指定してください:
(ヘルプを表示するには、「!?」と入力してください。)
Age: !?
年齢を入力してください
Age: 
# Position
Function SampleFunction7{
    Param(
        [Parameter(Position=3)]
        [Int] $C,
        [Parameter(Position=1)]
        [Int] $A,
        [Parameter(Position=2)]
        [Int] $B
    )
    Write-Host '$A is ' $A;
    Write-Host '$B is ' $B;
    Write-Host '$C is ' $C;
}

PS> SampleFunction7 1 2 3
$A is  1
$B is  2
$C is  3
# ValueFromPipeline
Function SampleFunction8{
    Param(
        [Parameter(ValueFromPipeline=$true)]
        [DateTime] $DateTime,
        [int] $AddDays = 0
    )
    $DateTime.AddDays($AddDays);
}

PS> Get-Date;
2017年12月27日 21:00:00
PS> Get-Date | SampleFunction8 -AddDate 3;
2017年12月30日 21:00:00
# ValueFromPipelineByPropertyName
Function SampleFunction9{
    Param(
        [Parameter(ValueFromPipelineByPropertyName=$true)]
        [Int] $Year,
        [Parameter(ValueFromPipelineByPropertyName=$true)]
        [Int] $Month,
        [Parameter(ValueFromPipelineByPropertyName=$true)]
        [Int] $Day
    )
    $Year;
    $Month;
    $Day;
}

Get-Date | SampleFunction9;
# ValueFromRemainingArguments
Function SampleFunction10{
    param (
        [int] $p1,
        [parameter(Position = 2)]
        [int] $p2,
        [parameter(ValueFromRemainingArguments=$true)]
        [Int[]] $others
    )
    $others;
}

PS> SampleFunction10 -p1 1 2 3 4 5
3
4
5

こんな感じで一つ

Windows PowerShellのFunction入門 (自動変数編)

Windows PowerShell

この記事はWindows PowerShellのFunctionが引数を受け取る際、自動変数をの$args、$_、$inputを使って読み出す話です

書いておいてなんですが (というか書いて実感したのですが)、Begin/Process/Endブロックを書かない (Processブロックのみの) Filterを書く時に$_を使い、それ以外の場合は自動変数を使わずにParamキィワードを使ったほうが良いです

引数名を指定せずに渡した値は$argsに配列として格納されます

Function SampleFunction1 {
    $args.GetType().Name;
    $args.Length;
    $args[0];
    $args[0].GetType().Name;
    $args[1];
    $args[1].GetType().Name;
}

PS> SampleFunction1 'a'  1;
Object[]
2
a
String
1
Int32

Pipelineから渡された値の受け取りは若干複雑です

Processブロックがある場合、$_にその時のpipelineから渡された値が格納されます

$_はProcessブロック開始前 (Beginブロック内) には存在していませんが、Endブロックで読み出せます (必然的にpipelineから渡された最後の引数が格納されています)

Function SampleFunction2 {
    Begin{
        'Begin';
        # $_; 実行するとエラーになる
    }
    Process{
        'Process';
        $_;
    }
    End{
        'End';
        $_;
    }
}

PS> 1,2,3 | SampleFunction2
Begin
Process
1
Process
2
Process
3
End
3

次に、pipelineの値はArrayList+ArrayListEnumeratorSimpleとして$inputに格納されます

Windows PowerShellではArrayList+ArrayListEnumeratorSimpleは.NETのIEnumerator インターフェイス (System.Collections)として実装されています

Windows PowerShell: These members are defined in the interface System.IEnumerator, which is implemented by the types identified below.

(中略)

Windows PowerShell: For $input, this type is System.Collections.ArrayList+ArrayListEnumeratorSimple.

$inputはBeginブロックでも読み出せますが値は入っておらず、何も入っていません

# 値は読み出せないが存在はしているので GetType() で型の名前は参照できる
Function SampleFunction3 {
    Begin{
        $input;
        $_.GetType().Name;
    }
}

PS> 1,2 | SampleFunction3
ArrayListEnumeratorSimple

Processブロックがあった場合、$_と同じ値を読み出せますが、1回読み出すと読み出せなくなります

Function SampleFunction4 {
    Process{
        $_;
        $input;
        $input;
    }
}
PS> 1,2 | SampleFunction4
1
1
2
2

ProcessブロックがなくEndブロックがあった場合、$inputは全てのpipelineから渡された値を配列として持っていますが、1回読み出すと読み出せなくなります

Function SampleFunction5 {
    End{
        $input;
    }
}

Function SampleFunction6 {
    End{
        $input;
        $input; # 2回目は読み出せないので、1回のみの場合と結果が同じになる
    }
}

PS> 1,2 | SampleFunction5
1
2
PS> 1,2 | SampleFunction6
1
2

ProcessブロックとEndブロックがあった場合、Processブロック内で読み出したかどうかに関わらず消費され、Endブロックでは読み出せなくなっています

Function SampleFunction7 {
    Process{}
    End{
        Write-Host 'End';
        $input; # Processブロックがあるため何も読み出せない
    }
}

PS> 1,2 | SampleFunction7
End

ここまで長々説明しておいてなんですが、$_はBegin/Process/Endブロックを書かない (Processブロックのみの) Filterをさっと書いてその場で処理する場合には便利ですが、$inputは癖があり、メンテナンス時にバグを作りこみそうな気がしますので自動変数は極力使わないのがよかろうと思います