On Sat, 2005-08-06 at 10:58 +0900, MURATA Makoto (FAMILY Given) wrote:
> Dave> <define name="anyuri">
> Dave>  <data type="string">
> Dave>  <param name="pattern">(([a-zA-Z][0-9a-zA-Z
> Dave> +\-\.]*:)?/{0,2}[0-9a-zA-Z;/?:@&amp;=+$\.\-_!
> Dave> ~*'()%]+)?(#[0-9a-zA-Z;/?:@&amp;=+$\.\-_!~*'()%]+)?</param>
> Dave>       </data>
> Dave> </define>
>
> This does not allow non-ASCII characters.  I am very sure that
> a lot of people want to use non-ASCII characters.
Noted. Thanks.

Eric also said:

If you really want a datatype that checks what's specify in the RFCs
that define the URI syntax and that you want that this datatype
preserves all spaces, the only solution is thus to apply a xs:pattern
facet on an xs:string.

Now, I don't think I would advise doing so. This syntax is really
complex to check, it can evolve in future versions and well known
so-called URIs do not meet this syntax anyway.


Summary. The problem as I see it is that Atom wants an element
content to be a URI (according to the RFC).
The perceived problem is that an Atom author will get a failure
(due to leading spaces etc), and not understand why.
Validating with msv or jing will confuse the user further.

Hence relax NG anyURI is unsuited
for their purpose (as currently worded).
Using a regex restricted String pattern is unlikely to be
successful over time.
Hence the specification text must be used to clarify.

More to the point, relax NG doesn't provide a way to validate
a URI 'as presented'. I can see the logic for this, but I
find it unsatisfactory. I can't see how schematron can help either.

regards DaveP.







YAHOO! GROUPS LINKS




Reply via email to