[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