[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] priority attribute question
I’m COMPLETELY fine with making RelaxNG
the headline featured normative schema, and with highlighting in big bold
letters the fact that the XSD version is illustrative only because it is not
able to express some of the constraints of the RelaxNG schema. So +1 to moving full speed ahead with just
the RelaxNG schema. Since I’ve spent enough time with it, I’ll
volunteer to update the XSD once the RelaxNG version is completely finished
(though I may need a little help with the attribute extensibility piece). =Drummond From: Gabe Wachob
[mailto:gabe.wachob@amsoft.net] Well, OK, but actually I think there are
very few developers who actually do use it – if we asked our current
developers, I’d guess they’d unanimously choose RelaxNG as a source
to work with. Also, the XSD wouldn’t be
“normative” because we’d be imposing constraints on it
outside of the schema – so while I’m OK with doing an XSD –
it would come with a lot of caveats, etc.. and require more time to get done.
(And then, we have *two* schemas
to debug, etc). In any case, I want to finish the RelaxNG schema
because doing so is uncovering issues here and there (which is good).
-Gabe From: Drummond Reed
[mailto:drummond.reed@cordance.net] My big concern is that so many developers
still use XSD that if we don’t even publish an XSD version, they will
find XRI and XRDS much harder to grok. We don’t want to put up barriers
to adoption. Besides the extensibility behaviour, what
other requirements from the RelaxNG version are hard or impossible to capture
in the XSD? I ask because if the extensibility issue is the primary one, we can
deal with that in external text, yet still offer an XSD that the vast majority
of implementers will be fine with. Anyone who wants to extend it SHOULD
understand and work with the RelaxNG version. How’s that sound? =Drummond From: I really don’t want to have to port
the relaxing thing to XSD – one of the reasons to go with RelaxNG was
that the only way to capture some of the important constraints was in
RelaxNG… Do people feel like XSD is worth it any
more? I don’t…
-Gabe From: Drummond Reed
[mailto:drummond.reed@cordance.net] Ah, Gabe, good catch, that’s my
mistake. The fact that the CanonicalID element allows the priority attribute
was a legacy of drafts before ED03 (or ED04, I can’t remember) when the
CanonicalID element cardinality was zero-or-more. Now that it is zero-or-one, neither the
CanonicalID or CanonicalEquivID should accept the priority attribute. BTW, are you going to also put out an
updated XSD schemas for XRDS and XRD when you are done? All these final fixes
should be reflected in both even if the RelaxNG version will be normative. Thanks, =Drummond From: I see the barx resolver returns me an XRD with a priority
attribute on the CanonicalID element. I was a bit surprised to see that since section 4.3.3 of
WD11/ED 06 doesn’t mention CanonicalID as an element that can have a
priority attribute and neither does section 4.2.3. I *do* notice that the XSD schema from WD11/ED
06 allows it. So which is it? What elements can have the priority
attribute?
-Gabe |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]