[
Lists Home |
Date Index |
Thread Index
]
jcowan@reutershealth.com (John Cowan) writes:
>Simon St.Laurent scripsit:
>
>> I think I've already made it clear that between MIME Content Type
>> registrations and the limited number of plausible generic schemes a
>> new registry is unnecessary.
>
>Why do only generic schemes count? What about idiosyncratic schemes?
If you want idiosyncratic schemes, I have no qualms about saying either:
1) Register a MIME Media Type and define your idiosyncratic scheme as
part of that
2) Name your scheme using a convention that isn't likely to produce
naming conflicts. Even the ugly x- convention warns that it's
non-standard, effectively screaming "idiosyncratic".
I have seen absolutely zero demonstration that the world needs as open
an approach as the URI-based QName system creates. Having created
several schemes myself, I think I'm in a decent position to guess what's
out there.
It is extraordinarily obvious that the URI-based QName system imposes
considerable overhead on any creating or processing XPointers which
happen to use non-W3C schemes.
I have seen no justification whatsoever that the verbosity or modeling
costs imposed by the QName system bring real benefits other than
consistency with the W3C's continuously growing fetish for QNames.
>> In any event, perhaps it's time to drop the notion that the world
>> must have an XML Fragment Identifier syntax by 31 December 2002.
>
>There's a confusion of levels going on here.
Not according to the pretensions of the XPointer Framework PR:
------------------------------
The framework is intended to be used as a basis for fragment identifiers
for any resource whose Internet media type is one of text/xml,
application/xml, text/xml-external-parsed-entity, or
application/xml-external-parsed-entity. Other XML-based media types are
also encouraged to use this framework in defining their own fragment
identifier languages.
------------------------------
RFC 3023 is cited normatively but no explicit reference to IETF process
is made.
Is "is intended" just a suggestion? Could be.
>It is the IETF, not the
>XML Linking WG, who is going to nail down the fragment-identifier
>syntax for documents of type text/xml and application/xml.
Correct.
>What the
>Linking WG has done is indicative but not determinative. The IETF may
>decide to use part of it, all of it, or none of it.
Correct, at least from an IETF perspective.
>Speaking for myself, I would like to see the IETF adopt the framework
>document (which includes the use of bare names) and the element()
>scheme only; all other schemes would be solely for other document
>types or for uses other than fragment identification.
Would that require the IETF to adopt the QName-based identification of
schemes? I don't see an easy way around accepting the framework
document without accepting that.
>> People definitely need a means of identifying fragments within XML
>> documents. It is not at all clear that they should be looking to the
>> W3C and its peculiar URI and QName biases for an answer.
>
>OTC, it is very clear that they should not. Only an update RFC to RFC
>2396 can do that job. The W3C as such cannot be an IETF member,
>because IETF members are individuals.
That sounds to me like you are making a case for the W3C stepping aside
completely in these matters, which seems unlikely, and I'm not quite
sure why you're referencing RFC 2396 in this context. Are you proposing
that an update to RFC 2396 should change the very foundations of
fragment identifiers? Could you please restate what you mean here?
-------------
Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid:1.3.6.1.4.1.6320 is another possibility altogether
|
