这是一篇关于在HTML和XHTML中使用自定义标签或属性并通过W3C验证的文章。
转自:http://www.alistapart.com/articles/customdtd/
现在HTML5貌似已经支持自定义属性了。
In his article in this issue, Peter-Paul Koch proposes adding custom attributes to form elements to allow triggers for specialized behaviors. The W3C validator won’t validate a document with these attributes, as they aren’t part of the XHTML specification. This article will show you how to create a custom DTD that will add those custom attributes, and will show you how to validate documents that use those new attributes. Here is a sample of the HTML with the custom attributes that let us specify the maximum length of a text area and whether a form element is required or not:
<form action="http://example.com/cgi-bin/example.cgi">
<p>
Name:
<input type="text" name="yourName" size="40" />
</p>
<p>
Email:
<input type="text" name="email" size="40"
required="true" />
</p>
<p>
Comments:<br />
<textarea maxlength="300" required="false"
rows="7" cols="50"></textarea>
</p>
<p>
<input type="submit" value="Send Data" />
</p>
</form>
What’s a DTD?
A Document Type Definition (DTD) is a file that specifies which elements and attributes exist in a markup language and where they can appear. Thus, the XHTML DTD specifies that <p> is a valid element, and that it can appear inside a <div>, but not inside a <b>. The URL at the end of your DOCTYPE declaration points to a place where you will find the DTD for the flavor of HTML you’re using. Neither your browser nor the W3C Validator goes out to the web to find the DTD — they have a “wired-in” list of the valid DOCTYPEs and use the URL for identification purposes only. As you will see later, this will change when you make a custom DTD.
Specifying the attributes
Adding attributes to an existing DTD is easy. For each attribute, you need to specify which element it goes with, what the attribute name is, what type of values it may have, and whether the attribute is optional or not. This information is specified in this model:
<!ATTLIST
elementName attributeName type optionalStatus
>
To add the maxlength attribute to the <textarea> element, you write this:
<!ATTLIST textarea maxlength CDATA #IMPLIED>
The CDATA specification means that the attribute value can contain any old character data you please; thus maxlength="300" or maxlength="ten" will both be valid. For “open-ended” data, DTDs don’t let you get more specific. The #IMPLIED specification means that the attribute is optional. A required attribute would specify #REQUIRED.
When you have a list of possible values for an attribute, you may specify them in the DTD. This is the case with the attribute named required, which has the values true and false. The values are case sensitive; in this example only the lowercase values are specified, so a value of TRUE would not be considered valid.
<!ATTLIST textarea required (true|false) #IMPLIED>
Confusion alert! This attribute is named “required,” but you don’t have to put it on every <textarea> element, so it’s an optional attribute.
The attribute named required should also be available to the <input> and <select> elements. All in all, the specifications to modify the DTD look like this:
<!ATTLIST textarea maxlength CDATA #IMPLIED>
<!ATTLIST textarea required (true|false) #IMPLIED>
<!ATTLIST input required (true|false) #IMPLIED>
<!ATTLIST select required (true|false) #IMPLIED>
Note: Adding new attributes to existing elements is easy; adding new elements is somewhat more difficult and beyond the scope of this article.
Placing the attributes
Now that you’ve defined the custom attributes, how do you place them where a validator can find them? The very best place to put them would be as the internal subset directly in your document:
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
[
<!ATTLIST textarea maxlength CDATA #IMPLIED>
<!ATTLIST textarea required (true|false) #IMPLIED>
<!ATTLIST input required (true|false) #IMPLIED>
<!ATTLIST select required (true|false) #IMPLIED>
]>
If you run such a file through the W3C validator, you find that it validates wonderfully well. If you download the sample files for this article and validate file internal.html, you can see this for yourself. Unfortunately, when you display the file in a browser, the ]> shows up on the screen. There’s no way around this bug, so this approach is right out.
Modifying the DTD
An approach that does workrequires you to obtain the XHTML transitional DTD and add your modifications to that file. The original version of the DTD is file xhtml1-transitional.dtd in directory dtd from this article’s sample files. You will also find three files with the .ent extension in that directory. These three files define all the entities that you use in HTML, such as ’ and ñ. You need to keep all these files together in the same directory.
The customized file, named xhtml1-custom.dtd was created by opening file xhtml1-transitional.dtd and adding the new attribute specifications at the end of the file. When adding attributes, you want to add your customizations at the end of the DTD to ensure that everything they need to reference has already been defined.
Changing the DOCTYPE
You must now change the <!DOCTYPE> in your HTML file to indicate that you are now using this custom “flavor” of XHTML. Since the custom DTD isn’t one of the publicly registered ones, the DOCTYPE will not use the PUBLIC specifier. Instead, you use the keyword SYSTEM followed by the location of the custom DTD. This may be a relative or absolute path name, or, if your DTD is on a server, a URL. The path must point to where your custom DTD really is! File custom.html in the sample files for this article uses a relative path name:
<!DOCTYPE html SYSTEM
"dtd/xhtml1-custom.dtd">
When you try to use the W3C validator on custom.html, it rejects the document because you aren’t using one of the validator’s approved DTDs.
Using a different validator
The solution is to use a different validator which will actually go out to the URL that you have specified and use it to check whether your document is valid or not. Because the document you’re validating is XHTML, you can use any XML parser that does validation. This article will uses the Xerces parser, available from xml.apache.org. This parser is written in Java™, so you will need to have Java installed on your system. When you unzip the Xerces download file, it will create a directory named xerces-2_6_2 (or whatever version is current). In the following text, the assumption is that you have unzipped it to the top level of the C: drive on Windows or to /usr/local on Linux.
One of the sample files that comes with Xerces is the Counter program. This program counts the number of elements, attributes, ignorable whitespaces, and characters appearing in an XML (or, in this case, XHTML) document. This program has an option to turn on validation as it parses the document, making it perfect for the task at hand. You run the Counter program (which is going to be your “validator”) from a batch file for Windows or a shell script for Linux. Here is the batch file, named validate.bat. It is all on one line, but shown here split across lines to fit on the page. Please note: there is a blank before the word dom and after the -v.
java -cp c:\xerces-2_6_2\xercesImpl.jar; »
c:\xerces-2_6_2\xmlParserAPIs.jar; »
c:\xerces-2_6_2\xercesSamples.jar dom/Counter -v »
%1 %2 %3 %4 %5 %6 %7 %8
Here is the Linux shell script, named validate.sh.
java -cp /usr/local/xerces-2_6_2/xercesImpl.jar:\
/usr/local/xerces-2_6_2/xmlParserAPIs.jar:\
/usr/local/xerces-2_6_2/xercesSamples.jar \
dom/Counter -v $1 $2 $3 $4 $5 $6 $7 $8
Of course, if you have unzipped Xerces to a different location, you will have to change the path names. Once this is all set up, you can validate the file custom.html by typing this on a Windows command line:
validate custom.html
Or this at a Linux shell prompt:
./validate.sh custom.html
If your file is valid, you will receive a message giving the filename and some statistics about the file, like this:
custom.html: 543;50;0 ms
(15 elems, 20 attrs, 9 spaces, 43 chars)
If the file isn’t valid, you will get error messages as well. For example, if you try to validate a file named badfile.html which contains these errors:
<p>Email: <input type="text" name="email" size="40"
required="yes" /></p>
<p>Comments:<br />
<textarea maxlength="300" inquirer="false"
rows="7" cols="50"></textarea>
You’ll get this output from the validator:
[Error] badfile.html:12:70: Attribute "required"
with value "yes" must have a value from the
list "true false ".
[Error] badfile.html:14:63: Attribute "inquirer"
must be declared for element type "textarea"
badfile.html:
611;82;0 ms (15 elems, 20 attrs, 9 spaces, 43 chars)
Another validation method
If you are using the jEdit editor, you may download the XML plugin. If you name your file with the extension .xhtml, jEdit will validate using your custom DTD as specified in the DOCTYPE.
Conclusion
It is easy to specify additional attributes for XHTML elements; with a little bit of work, you can set up a validator to check your files against your custom version of HTML. Download all the sample files from this article and give it a whirl.
About the Author
J. David Eisenberg is a programmer and teacher living in San Jose, CA with his cats, Marco Polo and Big Tony. He has written a book about Scalable Vector Graphics. He is also interested in the OpenDocument Format and foreign language learning.
转自:http://www.alistapart.com/articles/customdtd/
现在HTML5貌似已经支持自定义属性了。
In his article in this issue, Peter-Paul Koch proposes adding custom attributes to form elements to allow triggers for specialized behaviors. The W3C validator won’t validate a document with these attributes, as they aren’t part of the XHTML specification. This article will show you how to create a custom DTD that will add those custom attributes, and will show you how to validate documents that use those new attributes. Here is a sample of the HTML with the custom attributes that let us specify the maximum length of a text area and whether a form element is required or not:
<form action="http://example.com/cgi-bin/example.cgi">
<p>
Name:
<input type="text" name="yourName" size="40" />
</p>
<p>
Email:
<input type="text" name="email" size="40"
required="true" />
</p>
<p>
Comments:<br />
<textarea maxlength="300" required="false"
rows="7" cols="50"></textarea>
</p>
<p>
<input type="submit" value="Send Data" />
</p>
</form>
What’s a DTD?
A Document Type Definition (DTD) is a file that specifies which elements and attributes exist in a markup language and where they can appear. Thus, the XHTML DTD specifies that <p> is a valid element, and that it can appear inside a <div>, but not inside a <b>. The URL at the end of your DOCTYPE declaration points to a place where you will find the DTD for the flavor of HTML you’re using. Neither your browser nor the W3C Validator goes out to the web to find the DTD — they have a “wired-in” list of the valid DOCTYPEs and use the URL for identification purposes only. As you will see later, this will change when you make a custom DTD.
Specifying the attributes
Adding attributes to an existing DTD is easy. For each attribute, you need to specify which element it goes with, what the attribute name is, what type of values it may have, and whether the attribute is optional or not. This information is specified in this model:
<!ATTLIST
elementName attributeName type optionalStatus
>
To add the maxlength attribute to the <textarea> element, you write this:
<!ATTLIST textarea maxlength CDATA #IMPLIED>
The CDATA specification means that the attribute value can contain any old character data you please; thus maxlength="300" or maxlength="ten" will both be valid. For “open-ended” data, DTDs don’t let you get more specific. The #IMPLIED specification means that the attribute is optional. A required attribute would specify #REQUIRED.
When you have a list of possible values for an attribute, you may specify them in the DTD. This is the case with the attribute named required, which has the values true and false. The values are case sensitive; in this example only the lowercase values are specified, so a value of TRUE would not be considered valid.
<!ATTLIST textarea required (true|false) #IMPLIED>
Confusion alert! This attribute is named “required,” but you don’t have to put it on every <textarea> element, so it’s an optional attribute.
The attribute named required should also be available to the <input> and <select> elements. All in all, the specifications to modify the DTD look like this:
<!ATTLIST textarea maxlength CDATA #IMPLIED>
<!ATTLIST textarea required (true|false) #IMPLIED>
<!ATTLIST input required (true|false) #IMPLIED>
<!ATTLIST select required (true|false) #IMPLIED>
Note: Adding new attributes to existing elements is easy; adding new elements is somewhat more difficult and beyond the scope of this article.
Placing the attributes
Now that you’ve defined the custom attributes, how do you place them where a validator can find them? The very best place to put them would be as the internal subset directly in your document:
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
[
<!ATTLIST textarea maxlength CDATA #IMPLIED>
<!ATTLIST textarea required (true|false) #IMPLIED>
<!ATTLIST input required (true|false) #IMPLIED>
<!ATTLIST select required (true|false) #IMPLIED>
]>
If you run such a file through the W3C validator, you find that it validates wonderfully well. If you download the sample files for this article and validate file internal.html, you can see this for yourself. Unfortunately, when you display the file in a browser, the ]> shows up on the screen. There’s no way around this bug, so this approach is right out.
Modifying the DTD
An approach that does workrequires you to obtain the XHTML transitional DTD and add your modifications to that file. The original version of the DTD is file xhtml1-transitional.dtd in directory dtd from this article’s sample files. You will also find three files with the .ent extension in that directory. These three files define all the entities that you use in HTML, such as ’ and ñ. You need to keep all these files together in the same directory.
The customized file, named xhtml1-custom.dtd was created by opening file xhtml1-transitional.dtd and adding the new attribute specifications at the end of the file. When adding attributes, you want to add your customizations at the end of the DTD to ensure that everything they need to reference has already been defined.
Changing the DOCTYPE
You must now change the <!DOCTYPE> in your HTML file to indicate that you are now using this custom “flavor” of XHTML. Since the custom DTD isn’t one of the publicly registered ones, the DOCTYPE will not use the PUBLIC specifier. Instead, you use the keyword SYSTEM followed by the location of the custom DTD. This may be a relative or absolute path name, or, if your DTD is on a server, a URL. The path must point to where your custom DTD really is! File custom.html in the sample files for this article uses a relative path name:
<!DOCTYPE html SYSTEM
"dtd/xhtml1-custom.dtd">
When you try to use the W3C validator on custom.html, it rejects the document because you aren’t using one of the validator’s approved DTDs.
Using a different validator
The solution is to use a different validator which will actually go out to the URL that you have specified and use it to check whether your document is valid or not. Because the document you’re validating is XHTML, you can use any XML parser that does validation. This article will uses the Xerces parser, available from xml.apache.org. This parser is written in Java™, so you will need to have Java installed on your system. When you unzip the Xerces download file, it will create a directory named xerces-2_6_2 (or whatever version is current). In the following text, the assumption is that you have unzipped it to the top level of the C: drive on Windows or to /usr/local on Linux.
One of the sample files that comes with Xerces is the Counter program. This program counts the number of elements, attributes, ignorable whitespaces, and characters appearing in an XML (or, in this case, XHTML) document. This program has an option to turn on validation as it parses the document, making it perfect for the task at hand. You run the Counter program (which is going to be your “validator”) from a batch file for Windows or a shell script for Linux. Here is the batch file, named validate.bat. It is all on one line, but shown here split across lines to fit on the page. Please note: there is a blank before the word dom and after the -v.
java -cp c:\xerces-2_6_2\xercesImpl.jar; »
c:\xerces-2_6_2\xmlParserAPIs.jar; »
c:\xerces-2_6_2\xercesSamples.jar dom/Counter -v »
%1 %2 %3 %4 %5 %6 %7 %8
Here is the Linux shell script, named validate.sh.
java -cp /usr/local/xerces-2_6_2/xercesImpl.jar:\
/usr/local/xerces-2_6_2/xmlParserAPIs.jar:\
/usr/local/xerces-2_6_2/xercesSamples.jar \
dom/Counter -v $1 $2 $3 $4 $5 $6 $7 $8
Of course, if you have unzipped Xerces to a different location, you will have to change the path names. Once this is all set up, you can validate the file custom.html by typing this on a Windows command line:
validate custom.html
Or this at a Linux shell prompt:
./validate.sh custom.html
If your file is valid, you will receive a message giving the filename and some statistics about the file, like this:
custom.html: 543;50;0 ms
(15 elems, 20 attrs, 9 spaces, 43 chars)
If the file isn’t valid, you will get error messages as well. For example, if you try to validate a file named badfile.html which contains these errors:
<p>Email: <input type="text" name="email" size="40"
required="yes" /></p>
<p>Comments:<br />
<textarea maxlength="300" inquirer="false"
rows="7" cols="50"></textarea>
You’ll get this output from the validator:
[Error] badfile.html:12:70: Attribute "required"
with value "yes" must have a value from the
list "true false ".
[Error] badfile.html:14:63: Attribute "inquirer"
must be declared for element type "textarea"
badfile.html:
611;82;0 ms (15 elems, 20 attrs, 9 spaces, 43 chars)
Another validation method
If you are using the jEdit editor, you may download the XML plugin. If you name your file with the extension .xhtml, jEdit will validate using your custom DTD as specified in the DOCTYPE.
Conclusion
It is easy to specify additional attributes for XHTML elements; with a little bit of work, you can set up a validator to check your files against your custom version of HTML. Download all the sample files from this article and give it a whirl.
About the Author
J. David Eisenberg is a programmer and teacher living in San Jose, CA with his cats, Marco Polo and Big Tony. He has written a book about Scalable Vector Graphics. He is also interested in the OpenDocument Format and foreign language learning.
分享到：
发表评论
-
AXIOM StAXUtils
2013-05-09 15:15 0一、使用StAXUtils来创建XMLOutputStrea ... -
AXIOM Serializer
2013-05-09 14:38 0一、XMLOutputStreamWriter 在Java ... -
AXIOM 创建XML对象模型
2013-05-09 10:06 0一、通过AXIOM创建XML对象模型的方法 1.手动创建 ... -
AXIOM
2013-05-03 11:01 0AXIOM笔记 定义： AXIOM（Axis O ... -
XPath
2013-04-27 11:32 0XPath使用路径的形式来查找一个XML文件中的目标节点。 ... -
XMLHttpRequest对象
2013-04-27 10:56 0所有现代的浏览器（IE7+、Firefox、Chrome、S ... -
XML学习
2013-04-27 09:30 0XML是什么？ XML称为可扩展标记语言（EXtens ...
相关推荐
Validating //控件数据效验时发生 Validated //数据效验完成后发生 更好的理解这两个事件
Measuring and increasing silent reading comprehension rates: Empirically validating a repeated readings intervention MEASURING AND INCREASING SILENT READING COMPREHENSION RATES: EMPIRICALLY ...
Validating CC/PP and UAProf Profiles
Creating a custom markup extension 37 Handling routed events 44 Chapter 2: Resources 51 Introduction 51 Using logical resources 52 Dynamically binding to a logical resource 57 Using user-...
基于小波相关向量机预测器的多功能自确认传感器故障检测和确认，申争光，宋凯，针对传统多功能传感器无法状态自确认的局限性，提出了一种基于小波相关向量机(WRVM)和多项式预测滤波器(PFP)的测量值及其不确定度的�
Laravel开发-validating 模型数据自动验证 .zip
Laravel开发-validating 模型数据自动验证 以trait的方式来实现雄辩数据模型保存的时候自动验证
2018-Standards and Guidelines for Validating NGS Bioinformatics Pipelines.pdf
Creating a Custom Data Mining Solution Validating a Data Mining Model Connecting to and Consuming a Data-Mining Model Using the Data Mining add-in for Excel Lab : Using Data Mining Creating a ...
错误详情：Error: got unexpected status: BAD_REQUEST – error validating channel creation transaction for new channel ‘mychannel’, could not succesfully apply update to template configuration: error ...
美食该如何制作？食品安全以什么为标准？...这么一份validating the safty of cooki...该文档为validating the safty of cooking procedures，是一份很不错的参考资料，具有较高参考价值，感兴趣的可以下载看看
Next you learn how to sort a data range on one column or on multiple columns and how to use a custom sort order, the Filter (AutoFilter) feature and the Advanced Filter feature to view data that meets...
Creating a custom validator 12 Composing multiple validators into a single reusable validator 18 Converting string inputs to objects 23 Chapter 2: Getting Down and Dirty with Forms and Form ...
验证字符串参数插件 验证字符串参数插件为Jenkins贡献了一种新的参数类型，该参数类型支持对用户输入的参数进行正则表达式验证。 用法 只要可以选择构建参数，就可以使用此插件，最常见的是在作业配置页面中通过...
安装k8s时需要用到flannel网络插件，有些下载地址有时打不开，这里备份一下。 yml内的镜像是quay.io/coreos/flannel:v0.12.0-amd64。 如果使用的是quay.io/coreos/flannel:v0.11.0-amd64，直接编辑yml全部替换即可。
jsf2.0数据校验，文档为英文，.. • Manual validation – Validation in the action controller method • Implicit automatic validation Tidh“id”ib – Type conversion and the “required” attribute ...
Data Mining: A Tutorial-Based Primer, Second Edition provides a comprehensive introduction to data mining with a focus on model building and testing, as well as on interpreting and validating results....
该项目为基于Pi-calculus以及BPEL和pi-calculus之间的转换的Web服务组合进行形式验证提供了一种工具。 该工具集成了两种形式的验证技术，可以自动验证。
Devise a custom mechanism to provide maximum flexibility to your application through routing Validate the user input on the client side using jQuery Enhance your applications using Bootstrap Explore ...
This PDF document describe the design idea and sample codes how to validate big data in spark job.