OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Processing of datatypeLibrary and ns attribute


I started to try to incorporate into the spec our decision on processing of
datatypeLibrary and ns attributes, but I found what I think is a problem
with our decision.

We decided

1. No transformation of ns attribute before comparison.

2. UTF-8/% transformation of datatype attribute

3. We want both the datatypeLibrary and ns attribute to be absolute URI
references

4. We don't want the datatypeLibrary to have a fragment identifier

5. 3 and 4 are not enforced by the parser but are merely recommendations for
the user

The problem is with 5.  Our reason for 5 was that we didn't want to make
implementors do RFC 2396 parsing.  However, we are already requiring this
for the href attribute on externalRef and include.  Clearly we need to be
consistent.  We should require RELAX NG validators to check in both places
or in neither place.

I have therefore spent some time investigating what exactly is involved in
enforcing the generic syntax of 2396. I *think* it's basically very simple.
However, I believe there's a problem with the modifications to RFC 2396 in
RFC 2732.  See my message at

http://lists.w3.org/Archives/Public/uri/2001Jul/0006.html

Also I think it's not satisfactory for RELAX NG validators to allow relative
URIs for the ns attribute, given that most W3C specs now make the behavior
of a document with relative namespace URIs completely undefined.  I think
RELAX NG validators need to reject schemas with relative URis as ns
attributes.  I also don't think it's acceptable to make the poor implementor
try and figure out exactly what the combination of RFC 2396, RFC 2372 and
XLink 5.4 amounts to.  This is really hard to figure out. The grammar in RFC
2396 is very complicated because it is explaining how things should be
processed, but in terms of the net result of what counts as a legal URI it
is massively simpler.  It's taken me almost an entire day to figure this
out, and I'm not sure I've got it right.

I think we should therefore proceed as follows.

a) We should have a general rule about what validation a RELAX NG validator
does for an attribute value in a schema that is URI reference, and this rule
should be applied consistently for the href, datatypeLibrary and ns
attributes.  This rule should be stated explicitly rather than (or maybe as
well as) indirectly in terms of RFC 2396, RFC 2372 and XLink 5.4.  We might
decide that the rule is "do nothing" or we might decide it's the rule I give
in the referenced message (assuming the URI people agree with my analysis).

b) In the case of ns and datatypeLibrary, as well as the checking in (a), a
RELAX NG validator should check it's not a relative URI. To check this, a
RELAX NG validator would simply check that the string starts with something
matching the regex:

  [a-zA-Z][-+.a-zA-Z]*:

c) In the case of datatypeLibrary, in addition to checking (a) and (b) a
RELAX NG validator should check it does not have a fragment identifier.  To
check this, a RELAX NG validator would simply check that the string does not
contain a #.

(b) and (c) are basically trivial and there seems no good reason to prevent
a RELAX NG validator from checking this.

James





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC