Bijan Parsia wrote:
EDITORIAL NOTE: Many of us found the organization of the spec, and
especially of the normative parts, very confusing. See:
<http://www.w3.org/mid/943ed7de-fbc9-4110-b17b-af9f8043a...@cs.man.ac.uk>
I suggest that "Usage" and "Examples" be consolidated, and that
there are two normative sections, "Syntax" and "Incorporating CURIEs
into Host Languages" which contain the respective constraints. The
second section could usefully be broken down into "XML host
languages" and "Non-XML host languages".
Thanks for this. We are already done with CR more or less, but I
will see what I can do.
I don't see how you can get out of CR to PR, looking at your
implementation report. At this stage, I'm now asking Sean, my AC rep,
to oppose such a transition.
Well - the implementation report has not been updated recently. I
didn't mean that we were transitioning tomorrow. But there are a number
of implementations and uses for CURIEs now. I believe we have satisfied
the CR exit criteria, or will have once we are done gathering the
information.
Speaking as a spec implementor who sincerely tried to use the CURIE
spec, I think there are problem that merit serious changes to the
design of the language. This means another LC, if I'm not mistaken.
Perhaps - not really up to me.
...
Well...if that means that we all reinvent ours, then I don't think
it's a good idea. For me, this means that the CURIE spec is not a rec
track sensible document, but would be better as a note.
CURIEs are in use in many rec track documents currently, as well as in
the RDFa Recommendation. The reason CURIEs are separated out is so that
all of these documents can have a consistent definition. I am
interpreting your core objection here that there are not defined
profiles that would make it easier to have such a consistent definition.
As I said, I am sure the working group will get back to you formally.
The concept of a CURIE, that is an abbreviation that maps to an IRI,
is general. The expression of that concept in a host language is
necessarily going to be related to that host language. For example,
were you to use CURIEs in HTML you would not want to use some "xml"
mechanism to map a prefix.
Sure, but, uhm, HTML is not an XML host language. And I'm confused as
to why we're talking syntax rather than processing.
I only mentioned it because you suggested defining a prefixing mechanism
in the XML namespace. I was pointing out that HTML wouldn't be able to
use such a mechanism. Sorry if I was unclear. Moreover, SPARQL would
not be able to use a similar mechanism. The ability to have the host
language define the syntactical mechanism is essential. I think I agree
it would be best if the resulting CURIEs were all similar - but as you
point out that is unlikely since there are different constraints that
host languages will want to put on the reference portion.
--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: sh...@aptest.com
