扩展XHTML过渡XSD [英] Extending the XHTML transitional XSD

查看:55
本文介绍了扩展XHTML过渡XSD的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,

我正在尝试为某些电子邮件模板文件编写验证器我们将b $ b用作我们电子商务应用程序的一部分(顺便提一下,在C#中并且我已经因为我不是XML的庞大用户而遇到了问题。


基本上电子邮件模板可以包含任何有效的XHTML,还有

标签,例如< membershipcardheaderand< membershipcardfoote,可以

出现在HTML正文的任何​​地方。


我已经设法从W3C下载XSD for XHTML

并且可以很好地验证普通XHTML文件,并且可以使用

简单的XML包含我的标签 - 但我不知道如何继续和

让.NET解析器从任何一个XSD验证?


或者可以我以某种方式从XHTML过渡中继承了我的XSD?我已经看了xsd:redefine标签,但不知道从哪里开始?


有人可以帮忙吗?

干杯,

Kieran

Hi all,
I''m attempting to write a validator for some email template files we
use as part of our e-commerce application (incidentally in C#) and I''ve
run into a problem as I''m not a huge user of XML.

Essentially an email template can contain any valid XHTML, but also has
tags such as <membershipcardheaderand <membershipcardfooterthat can
appear anywhere in the body of the HTML.

I''ve managed to download the XSD for XHTML transitional from the W3C
and can validate plain XHTML files fine, and can do the same with
simple XML containing my tags - but I have no idea how to proceed and
get the .NET parser to validate from either of the XSD''s?

Or can I somehow inherit my XSD from the XHTML transitional one? I''ve
looked at the xsd:redefine tag but have no idea where to start?

Can anyone assist?

Cheers,
Kieran

推荐答案



看看XHTML模块化,

使用自定义标签扩展xhmlt规范似乎很有用。


有什么东西在w3c官方网站上的XHTML部分,如下所示:

http://www.w3.org/MarkUp/Guide/xhtml-m12n-tutorial/

Hi,

take a look at XHTML modularization,
it seems useful to extend the xhmlt specs with custom tags.

There''s something in the XHTML section on w3c official site, like this:

http://www.w3.org/MarkUp/Guide/xhtml-m12n-tutorial/




Kidogg写道:

Kidogg wrote:

基本上电子邮件模板可以包含任何有效的XHTML,但也有

标签,如< membershipcardheaderand< membershipcardfoote,它可以

出现在HTML正文的任何​​地方。
Essentially an email template can contain any valid XHTML, but also has
tags such as <membershipcardheaderand <membershipcardfooterthat can
appear anywhere in the body of the HTML.



HTML电子邮件是令人厌恶的,XHTML是双倍的。


虽然XHTML路线添加这些元素是显而易见的(看看

模块化的XHTML)你正在越来越远离今天的'实际可用的HTML版本'的客户。我会

强烈建议你坚持使用HTML 4.01作为任何公共的使用

HTML。


还有一个严重的问题,为什么你需要包含新标签
$ b公开发布内容中的$ b。如果他们是新的和未知的,那么

客户期望与他们做什么?如果它们无法使用,为什么

包括它们?


假设它们对你的内部CMS非常重要,那么我会是
强烈倾向于在内部使用命名空间的XHTML

(可能只是XHTML 1.0 Strict),然后用最终的

"去掉它们;转录出版物步骤,可能在XSLT中,也将

转换为HTML 4.01。这也是明文电子邮件的可用路径。


PS - 发送HTML电子邮件给我,它直接进入/ dev / null /你

_are_ going支持明文,不是吗?

HTML email is an abomination, XHTML doubly so.

Although the "XHTML route" to adding these elements is obvious (look at
modularized XHTML) you''re heading further and further away from what''s
a realistically usable version of HTML for today''s clients. I''d
strongly recommend that you stick with HTML 4.01 as any "public" use of
"HTML".

There''s also a serious question as to why you need to include new tags
in publically published content. If they''re new and unknown, then
what''s the client expected to do with them ? If they''re unusable, why
include them ?

Assuming that they''re significant for your in-house CMS, then I''d be
strongly inclined to use them internally with namespaced XHTML
(probably just XHTML 1.0 Strict), then strip them out with a final
"transcode for publication" step, possibly in XSLT, that also converts
it to HTML 4.01. This is also a usable route to plaintext email.

PS - send HTML email to me and it goes straight into /dev/null/ You
_are_ going to support plaintext, aren''t you?




Andy Dingley写道:

Andy Dingley wrote:

Kidogg写道:
Kidogg wrote:

基本上电子邮件模板可以包含任何有效的XHTML,但也有

标签,例如< membershipcardheaderand< membershipcardfoote,它可以

出现在HTML正文的任何​​地方。
Essentially an email template can contain any valid XHTML, but also has
tags such as <membershipcardheaderand <membershipcardfooterthat can
appear anywhere in the body of the HTML.



HTML电子邮件是令人厌恶的,XHTML是双倍的。


HTML email is an abomination, XHTML doubly so.



证明你自己。仅仅因为我们提供HTML电子邮件模板并不是因为
意味着它们是大量膨胀或可怕的格式化。一些

我们的客户只是要求他们可以控制输出电子邮件的

格式。

Justify yourself. Just because we provide HTML email templates does not
mean that they are massively bloated or horrendously formatted. Some of
our clients simply request that they can have some control over the
formatting of their outputted email.


>

虽然XHTML路线添加这些元素是显而易见的(看看

模块化的XHTML)你正在越来越远离今天的'实际可用的HTML版本'的客户。我会

强烈建议你坚持使用HTML 4.01作为任何公共的使用

HTML。
>
Although the "XHTML route" to adding these elements is obvious (look at
modularized XHTML) you''re heading further and further away from what''s
a realistically usable version of HTML for today''s clients. I''d
strongly recommend that you stick with HTML 4.01 as any "public" use of
"HTML".



我们的网页完全符合XHTML标准,我们没有任何问题 -

在浏览器方面几乎全面兼容>
(包括移动设备)。关于

使用XHTML而不是4.01你有什么问题?

Our webpages are fully XHTML strict compliant and we have no issues -
practically full compatibilty across the board in terms of browsers
(including mobile devices). What issues are you aware of regarding
using XHTML as opposed to 4.01?


>

那里'这也是一个严肃的问题,为什么你需要在公开发布的内容中加入新标签

。如果他们是新的和未知的,那么

客户期望与他们做什么?如果它们无法使用,为什么

包括它们?
>
There''s also a serious question as to why you need to include new tags
in publically published content. If they''re new and unknown, then
what''s the client expected to do with them ? If they''re unusable, why
include them ?



重点是它们不包含在发送的最终电子邮件中。它们是模板系统的一部分,我们有XML电子邮件模板

,我希望验证这些模板可以阻止我们的客户在格式错误的XML格式下拍摄自己的价格。

The point is that they are not included in the final email that is
sent. They are part of a templating system, we have XML email templates
that I wish to validate to stop our clients shooting themselves in the
feet with badly formed XML.


>

假设它们对你的内部CMS非常重要,那么我就是

强烈倾向于在内部使用命名空间的XHTML

(可能只是XHTML 1.0 Strict),然后用最终的

转码用于发布将它们删除。步骤,可能在XSLT中,也将

转换为HTML 4.01。这也是明文电子邮件的可用途径。
>
Assuming that they''re significant for your in-house CMS, then I''d be
strongly inclined to use them internally with namespaced XHTML
(probably just XHTML 1.0 Strict), then strip them out with a final
"transcode for publication" step, possibly in XSLT, that also converts
it to HTML 4.01. This is also a usable route to plaintext email.



我们已经采取了哪些措施来获取纯文本输出。这并不是
解决了在第一个

地方尝试验证模板的问题。

Which is what we already do to get our plaintext output. This does not
solve the problem of trying to validate the templates in the first
place however.


>

PS - 发送HTML电子邮件给我,它直接进入/ dev / null /你

_are_支持明文,不是吗?
>
PS - send HTML email to me and it goes straight into /dev/null/ You
_are_ going to support plaintext, aren''t you?



首先,如上所述,当然我们这样做,其次,你不是b
b必然是典型的电子邮件接收者市场人口

我们的系统 - 只是因为你更喜欢纯文本并不适用于

所有用户。


问候,
Kieran

Firstly, as above, of course we do, and secondly, you are not
necesarily the typical market demographic for recepients of emails from
our system - just because you prefer plain text does not hold true for
all users.

Regards,
Kieran


这篇关于扩展XHTML过渡XSD的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆