Victor Mote | 1 Jun 01:16 2007

lengths and percentages


Dear Editors:

I see that the definition of <length-range> has changed from 1.0 to 1.1 to
explicitly differentiate between the <length> datatype and the <percentage>
datatype. This makes intuitive sense, and the clarification is welcome.
However, there is still at least one place in the 1.1 Recommendation that
confuses or even contradicts this distinction, at Section 5.11, at the first
"Note" item (designated by a hand with a pointing finger in the PDF
version), which says: "Since a <percentage> value, that is not interpreted
as "auto", is a valid <length> value it may be used in a short form."

It is difficult to tell whether this is intended to be a general statement
for all cases, or one that applies only to the "space-before" example in the
context. However, neither seems to be appropriate. The "space-before"
property says that percentages are "N/A". And, if my understanding is
correct that "86%" should not be accepted as a valid <length> item (although
it should be accepted as a valid percentage item where percentages are
valid), then the statement is not correct for the general case either.

On a related note, it seems to me that the "Value" definitions for the
space-end, space-start, and leader-length properties (and perhaps other
similar properties) are not quite correct, or at least not as clear as they
could be:
1. It may be appropriate to clarify the definition of the <space> datatype
in a manner similar to the way <length-range> was clarified, that is, by
adding the comment that "A property may define ... additional permitted
values and their semantics; e.g. ... <percentage>."
2. My understanding of the Recommendation taken as a whole is that it is not
accurate for any of the three properties mentioned (and perhaps others) to
(Continue reading)

Adrian Paschke | 11 Jun 22:23 2007
Picon

REMINDER CfP RuleML-2007


Dear Prospective Author of RuleML-2007,

This is just a friendly reminder that the deadline for the RuleML-2007
abstract submission is

      Friday, June 15, 2007.

Please upload a plain text abstract in our EasyChair submission page at
http://www.easychair.org/RuleML2007/.

All information regarding submission requirements are
elaborated in the RuleML-2007 web site at:

http://2007.ruleml.org/index-Dateien/Page577.htm

Sincerely,

Adrian Paschke
Yevgen Biletskiy

RuleML-2007 Program Co-Chairs

[ our apologies should you receive this message more than one time ]

             The International RuleML Symposium
        on Rule Interchange and Applications (RuleML-2007)

           October 25-26, 2007, Orlando, Florida

(Continue reading)

Kristof Zelechovski | 15 Jun 12:50 2007
Picon

file URL is overspecified

The URI reference in the HTML 4 refers to RFC 2396 which is obsolete by RFC 3986.  The latter document has a new section 2.5: "Identifying Data", containing the following new material:

URI characters provide identifying data for each of the URI components, serving as an external interface for identification between systems.  Although the presence and nature of the URI production interface is hidden from clients that use its URIs (and is thus beyond the scope of the interoperability requirements defined by this specification), it is a frequent source of confusion and errors in the interpretation of URI character issues.  Implementers have to be aware that there are multiple character encodings involved in the production and transmission of URIs: local name and data encoding, public interface encoding, URI character encoding, data format encoding, and protocol encoding.

Local names, such as file system names, are stored with a local character encoding.  URI producing applications (e.g., origin servers) will typically use the local encoding as the basis for producing meaningful names.  The URI producer will transform the local encoding to one that is suitable for a public interface and then transform the public interface encoding into the restricted set of URI characters (reserved, unreserved, and percent-encodings). Those characters are, in turn, encoded as octets to be used as a reference within a data format (e.g., a document charset), and such data formats are often subsequently encoded for transmission over Internet protocols.

The new statements above are slightly incompatible with what HTML URI encoding specification says:

URIs do not contain non-ASCII values

That statement is true for what the RFC calls "public interface encoding": it seems reasonable that the user agent should use an URL when it requests an external resource; however, requiring that HTML documents should use a public URI for resources that the user agent is expected to serve without communicating with an external server, such as local files identified using then file scheme, seems an excessive complication to me.  Internet Explorer does not respect this prohibition because it uses IRIs, not URIs, internally, and converts them to URLs if needed when it communicates with an external server.  If an external URL is specified in the source document as percent-encoded, it is passed without altering because encoding is not needed and the server is responsible for decoding; however, there is no server to decode a local URL and it remains unresolved.  That is not compliant with the current standard, but I think in this case the implementation is right and the standard needs some freedom with respect to local URLs.

Of course, one could always do away with an argument that an HTML document containing reference to a local resource cannot be published and can be authored as noncompliant.  However, this is only partially true.  The reason is that the prohibition of B.2.1 propagated to the XSLT specification that refers to it explicitly where it specifies how URI attributes should be transformed in html mode.  In effect, a document produced by a conforming XSLT processor for local usage is perfectly valid and perfectly useless: hyperlinks are broken and images do not show up.

·        My suggestion: The constraints for URLs denoting local resources should be relaxed.

I understand that this is fixed by HTML 5, so this is perhaps the good news:

The href content attribute, if specified, must contain a URI (or IRI).

Best regards,

Christopher Yeleighton

Michael Kay | 15 Jun 14:11 2007
Picon

RE: file URL is overspecified

>The reason is that the prohibition of B.2.1 propagated to the XSLT specification that refers to it explicitly where it specifies how URI attributes should be transformed in html mode.  In effect, a document produced by a conforming XSLT processor for local usage is perfectly valid and perfectly useless: hyperlinks are broken and images do not show up.
 

To help you get round the difference between what the HTML spec says and what current browsers do, XSLT 2.0 introduced the serialization parameter escape-uri-attributes="no", giving the XSLT author control over whether and which URIs in generated HTML pages are percent-encoded. Of course, this is only a small amelioration to this messy problem; but it helps.
 
Michael Kay

From: xsl-editors-request <at> w3.org [mailto:xsl-editors-request <at> w3.org] On Behalf Of Kristof Zelechovski
Sent: 15 June 2007 11:50
To: www-html <at> w3.org
Cc: 'Tim Berners-Lee'; xsl-editors <at> w3.org; whatwg <at> whatwg.org
Subject: file URL is overspecified

The URI reference in the HTML 4 refers to RFC 2396 which is obsolete by RFC 3986.  The latter document has a new section 2.5: "Identifying Data", containing the following new material:

URI characters provide identifying data for each of the URI components, serving as an external interface for identification between systems.  Although the presence and nature of the URI production interface is hidden from clients that use its URIs (and is thus beyond the scope of the interoperability requirements defined by this specification), it is a frequent source of confusion and errors in the interpretation of URI character issues.  Implementers have to be aware that there are multiple character encodings involved in the production and transmission of URIs: local name and data encoding, public interface encoding, URI character encoding, data format encoding, and protocol encoding.

Local names, such as file system names, are stored with a local character encoding.  URI producing applications (e.g., origin servers) will typically use the local encoding as the basis for producing meaningful names.  The URI producer will transform the local encoding to one that is suitable for a public interface and then transform the public interface encoding into the restricted set of URI characters (reserved, unreserved, and percent-encodings). Those characters are, in turn, encoded as octets to be used as a reference within a data format (e.g., a document charset), and such data formats are often subsequently encoded for transmission over Internet protocols.

The new statements above are slightly incompatible with what HTML URI encoding specification says:

URIs do not contain non-ASCII values

That statement is true for what the RFC calls "public interface encoding": it seems reasonable that the user agent should use an URL when it requests an external resource; however, requiring that HTML documents should use a public URI for resources that the user agent is expected to serve without communicating with an external server, such as local files identified using then file scheme, seems an excessive complication to me.  Internet Explorer does not respect this prohibition because it uses IRIs, not URIs, internally, and converts them to URLs if needed when it communicates with an external server.  If an external URL is specified in the source document as percent-encoded, it is passed without altering because encoding is not needed and the server is responsible for decoding; however, there is no server to decode a local URL and it remains unresolved.  That is not compliant with the current standard, but I think in this case the implementation is right and the standard needs some freedom with respect to local URLs.

Of course, one could always do away with an argument that an HTML document containing reference to a local resource cannot be published and can be authored as noncompliant.  However, this is only partially true.  The reason is that the prohibition of B.2.1 propagated to the XSLT specification that refers to it explicitly where it specifies how URI attributes should be transformed in html mode.  In effect, a document produced by a conforming XSLT processor for local usage is perfectly valid and perfectly useless: hyperlinks are broken and images do not show up.

·        My suggestion: The constraints for URLs denoting local resources should be relaxed.

I understand that this is fixed by HTML 5, so this is perhaps the good news:

The href content attribute, if specified, must contain a URI (or IRI).

Best regards,

Christopher Yeleighton

Kristof Zelechovski | 17 Jun 11:15 2007
Picon

RE: file URL is overspecified

MSXML does not respect the attribute escape-uri-attributes.  It seems the best way to go in the Microsoft world is to use XML mode output mode to generate XHTML and convert it to HTML using the native HTML Document object.  This was not particularly difficult, you can see the source code here.  I admit it is rather inefficient but I wanted to use existing components and to make the code short—the code is still too long to just paste it.

On the other hand, if you want to use the xsl-stylesheet instruction to generate the HTML code on the fly, it is possible to fix the broken links using decodeURI in the onLoad event handler; the downside is that the page will flash because the images will be invalid on the outset.

That was just for the record, sorry for disturbing you if consider this information useless.  I shall welcome all your comments otherwise.

Best regards

Christopher Yeleighton

 

From: Michael Kay [mailto:mhk <at> mhk.me.uk]
Sent: Friday, June 15, 2007 2:12 PM
To: 'Kristof Zelechovski'; www-html <at> w3.org
Cc: 'Tim Berners-Lee'; xsl-editors <at> w3.org; whatwg <at> whatwg.org
Subject: RE: file URL is overspecified

 

>The reason is that the prohibition of B.2.1 propagated to the XSLT specification that refers to it explicitly where it specifies how URI attributes should be transformed in html mode.  In effect, a document produced by a conforming XSLT processor for local usage is perfectly valid and perfectly useless: hyperlinks are broken and images do not show up.

 

To help you get round the difference between what the HTML spec says and what current browsers do, XSLT 2.0 introduced the serialization parameter escape-uri-attributes="no", giving the XSLT author control over whether and which URIs in generated HTML pages are percent-encoded. Of course, this is only a small amelioration to this messy problem; but it helps.

 

Michael Kay

Michael Kay | 17 Jun 13:46 2007
Picon

RE: file URL is overspecified

 

MSXML does not respect the attribute escape-uri-attributes.   

 

MSXML doesn't implement XSLT 2.0, so that's not surprising. I think you have an issue with the products and not with the W3C specs, so this list isn't going to help you much.

 

Michael Kay

http://www.saxonica.com/ 

Adrian Paschke | 23 Jun 00:21 2007
Picon

2nd CfP RuleML-2007, Springer Confirmed, Submission Deadline Extended to July 20th


    [Apologies if you receive this more than once]

              The International RuleML Symposium
         on Rule Interchange and Applications (RuleML-2007)

               October 25-26, 2007, Orlando, Florida

                       http://2007.ruleml.org

Dear Colleagues,

Due to numerous requests about conflicting deadlines, and with Springer
as confirmed publisher, online submissions to RuleML-2007 will be
allowed until July 20 (hard deadline):

Abstract submission before         July 10, 2007
Paper submission due               July 20, 2007
Notification of acceptance         August 6, 2007
Final submissions due              August 23, 2007

The International RuleML Symposium on Rule Interchange and Applications
(RuleML-2007) will take place, October 25-26, 2007, in Orlando, Florida
http://2007.ruleml.org, co-located with The 10th International Business
Rules Forum <http://www.businessrulesforum.com>. RuleML-2007 is devoted
to practical distributed rule technologies and rule-based applications
which need language standards for rules operating in the context of,
e.g., the Semantic Web, Web 2.0/3.0, Intelligent Multi-Agent Systems,
Event-Driven Architectures, Service-Oriented Computing Applications and
Rule-based Enterprise Application Systems. A RuleML-2007 Challenge with
prizes will be organized to demonstrate tools, use cases, and applications.

        Call for Papers:  http://2007.ruleml.org/cfp.pdf

Highlights:

- Accepted papers will be published as Springer LNCS proceedings
- 2 Keynote speakers; Confirmed Keynote by J├╝rgen Angele (Ontoprise):

     "Rule-based Development Support in the Automotive Industry"

- In cooperation with ECCAI (confirmend) and IEEE Computer TCAAS
- Selection of revised papers will be resubmitted to a special journal issue
- Best Paper Award
- Prestigious prizes will be awarded to the first two best applications
of the Challenge
- Panel by world-class scientists and practitioners, featuring topics on
event and rule-based computing and industry success stories

Updates:

1) Modified Challenge Requirements:

"Submissions to the RuleML Challenge 2007 consist of a demo paper of 3-5
pages, describing the demo show case, and a link to more information
about the demo/show case, e.g. a project site, an online demonstration,
a presentation about the demonstration, or a download site for the
demonstration.

The show case should demonstrate the use of rules of various kinds in
interesting and practically relevant ways, preferably (but not
necessarily) embedded into a Web-based or distributed environment."

More information regarding submissions can be found in the RuleML-2007
web site:

http://2007.ruleml.org/index-Dateien/Page787.htm

2) Enhanced Topics:

- Rules in Web 2.0 and Web 3.0
- Rules in Semantic Web Technologies
- Rules in Web Intelligence Research

We invite submissions of full, short and demo papers related (but not
limited) to one or more of the topics listed at:

http://2007.ruleml.org/index-Dateien/Page431.htm

3)  All papers and demos will  be carefully peer-reviewed by 3 PC
members of the Program Committee:

http://2007.ruleml.org/index-Dateien/Page508.htm

Sincerely,

General Chair

Said Tabet, Inferware Corp.
stabet AT ruleml.org

Program Co-Chairs

Adrian Paschke, Technical University Munich, Germany
paschke AT in.tum.de
Yevgen Biletskiy, University of New Brunswick, Canada
biletski AT unb.ca

Challenge Co-Chairs

Alexander Kozlenkov, Betfair Ltd., London, UK
alex.kozlenkov AT betfair.com
Ralph Hodgson, TopQuadrant, Inc., Mountain View, USA
rhodgson AT topquadrant.com

Panel Chair

John Hall, Model Systems, UK
john.hall AT modelsys.com

Publicity Chair

Suzette Stoutenburg, MITRE Corporation, USA
suzette AT mitre.org

xslt

Hello:

 

Please, how can I get the xslt file and the engine to obtain the report?

 

Thank you.

 

Francisco Javier Martín
Desarrollo de Proyectos - Valladolid
Security Solutions & Services Division

Edif. Solar, Of. 13, 14, 15
Parque Tecnológico Boecillo.
47151 Valladolid. España
Tel.: 983 54 65 55   Fax: 983 54 66 09

 

 

AVISO LEGAL: La informacion contenida en este mensaje y cualquier documento adjunto en el mismo es confidencial, puede estar legalmente protegida y esta dirigida solamente al destinatario. La publicacion, uso, distribucion, impresion o copia no autorizada del contenido de este mensaje, esta estrictamente prohibida y puede ser ilegal. Si Vd. ha recibido este mensaje por error, le rogamos destruya el mensaje y lo notifique al remitente o llame al telefono (+34) 91 556 92 62.

DISCLAIMER: The information contained in this message and any attached document is confidential, covered by law and intended solely for the recipient. The distribution, print, publication, unauthorised copy and / or use of the message content is strictly forbidden and could be deemed illegal. If you are not the intended recipient of this message, we request that you destroy it and notify the sender either in writing or by calling ++34 91 556 92 62.

 


Gmane