See also: IRC log
<Norm> Scribe: Norm
<scribe> ScribeNick: Norm
Vincent: identified about a dozen issues that
look like they're in a questionable status
... we're just going to see what the state is, not spend a
lot of time on any of them
VQ: 12 May 2004, deferred
Roy: Updated in Boston?
timbl: Action was on Roy to write something; that action was dropped on 10 Aug 2004
Roy: Area directors said, if you think the RFC applies, it does. If you say it doesn't, it doesn't.
timbl: Let's update the issue to point to this
discussion and leave it deferred
... if we're going to check some things, we should leave
them open
... and check them periodically
VQ: status is unclear. Per transition history, it's still open, but on 27 Mar 2005 DanC asserted it was closed in Basel
ht: There's new information here, we've
published a first WD of XLink 1.1.
... there are three branches to the criticism: (1) you
can't have two linking attributes on the same element; (2)
you have to use the namespace on the attribute; and (3) you
have to have two attributes: xlink:type and
xlink:href
... We've fixed (3) in XLink 1.1.
<timbl> > May 2004 discussion
Norm: I think the paragraph in 4.5.2 of WebArch V1 closes this issue
General agreement
VQ: last action was on Chris to draft a
finding, which was done
... but it's clearly a draft
Norm: I think 4.3 of WebArch V1 closes this issue
Vincent: I don't think there's anything in the finding that isn't in WebArch, it's just presented differently
timbl: I agree we can close the issue, I
wonder if the draft finding should be taken off the list of
drafts and move it to a list of historical findings
... or ask Chris if he'd be willing to finish it in his
spare time
<scribe> ACTION: VQ to ask Chris if he's interested in finishing contentPresentation-26 finding, in which case we'll review it, or if he's content to have it moved to an "historical documents" section [recorded in http://www.w3.org/2005/09/21-tagmem-irc]
VQ: last discussion in May 2004
Roy: we should add links to the finished IRI
spec (RFC 3987)
... the original question was, should XML use IRI? Now that
it has a definition that's been agreed upon, yes, they
should
Noah asks about the direction Schema chose
ht: Schema decided not to rename anyURI, but we agreed it should be used for IRIs now
timbl: because it's not constrained?
ht: right, the constraints are insufficient to
interefere with IRI
... general consensus was that the constraints were more
trouble than they're worth
... discussion in the Schema WG ensued...the WG decided to
back out all syntactic checking of anyURI
... anyURI is a synonym for string that you use to document
your intent. Applications are allowed to do what they want
after validity assessment
timbl: that's clear when it comes to
schema.
... there were two parts, what to do about the fact that it
isn't an RFC?
... that's been fixed
... and should we encourage folks to use them
ht: but beware of the security constraints (phishing attempts)
noah: we could clarify a point of confusion in that http doesn't use IRI
Roy: but that's not a confusion; http doesn't use href attributes either
noah: it's a potentially confusing that they aren't IRI on the wire
Roy: but that's true now, the toolbar doesn't
send what you type now, it adds the http:// part, changes
spaces, etc.
... the issues is named IRIEverywhere, but the real
question was in XML. In XML and HTML, I think they should
use it. The focus there should be on making I18N content
easy to use
... web servers don't *want* IRI, it gives them lots of new
names for the same resource
noah: I'm speculating that it might be worth
it for the TAG to set down basically what Roy just said.
You might think that URIs are all historical accidents now,
but that's not true, it's intentional that there are two
layers here.
... I don't feel invested enough to say for sure that we
should do it, but it looks like a possibility
<Roy> http://www.w3.org/2003/04/iri.html
Some discussion of mappings and identity in URI/IRI
<timbl> Summary of conclusion: We should deprecate passing IRIs in non-canonical form (As we have for URIs). Also we should change the namespace spec as it is inconsistent with reality of different equivalent URIs. But there are more things in the conclusion
Norm: Getting agreement that you *should* use canonical forms for namespace URIs and you *should not* use two different spellings for the same thing is probably pretty easy. It'll be trickier to get agreement on how much canonicalization you have to do
noah: I thought a compromise had been reached
that for things like namespaces, we'd do "equal/not equal"
so that we had interoperability, etc.
... this means you can have two attributes with namespace
names that are the same under some other comparison rules
timbl: you can never say that two things are
different, you can only tell if they're the same
... it says that if you use two different URIs for the
namespace name that look different but are the same, it's
ok
... what it should say is that it doesn't catch that error,
it may still be an error
noah: it doesn't define ok, it just makes two piles, valid and not valid
Norm: timbl seems to be suggesting a new class "not invalid" and we don't have
<timbl> Tim: No, I'm not
<ht> Let's see what Namespaces 1.1 actually says, http://www.w3.org/TR/xml-names11/#dt-identical
ht: I don't think there's a bug here
timbl: supposing I write a parser which canonicalizes?
ht: then it isn't Namespaces 1.1 conformant
timbl: then I think that's a problem because
canonicalization is useful
... canonicalization is something that a library might do
<noah> From: http://www.w3.org/TR/xml-names11/#uniqAttrs
timbl: and if we're recommending C14N then it's a good thing to do
<noah> In XML documents conforming to this specification, no tag may contain two attributes which:
<noah> have identical names, or
<noah> have qualified names with the same local part and with prefixes which have been bound to namespace names that are identical.
Roy: what this document says is that you can't do that C14N
noah: that's what this spec says, I don't see any reason why we couldn't define another layer with a different spec that asserted more agressive checks
ht: the IRI spec itself blesses this in 5.x.x
Roy: that's ok, but the false statement is in
the examples in 2.3 of Namespaces 1.1
... It's wrong to say that these URIs are different for
purposes of identifying namespaces
... IRIs don't identify different things depending on the
context in which they're used
ht: I'm pretty sure "identifying" here is intended to refer to the word "idnetical" above although it's open to the broader interpretation Roy made
Roy: it would be better if it said it isn't necessary to C14N the strings, but if a user does that, it's a user error.
ht: that's a real substantive change
noah: it's very important to me that the spec
define the same behavior for all implementations
... we have to say that all implementations must do this or
must not, what you can't do is open up the interop holes
Roy: I'll accept the notion that it's desirable not to get user problem reports, I don't think there's any situation where all software will give the same behavior in the case of user error
<timbl> Bug: 'To conform to this specification, a processor MUST report violations of namespace well-formedness, with the exception that it is not REQUIRED to check that namespace names are legal IRIs."
Noah continues to extole the virtues of string compare for interop
<timbl> Should be 'To conform to this specification, a namespace-validating processor MUST report violations of namespace well-formedness, with the exception that it is not REQUIRED to check that namespace names are legal IRIs."
timbl: asks about using two Xlink attributes
ht: one of them, and only one of them, is
character-for-character the same as the
character-for-character string that defines the XLink
namesapce
... calling them URIs was a mistake and calling them IRIs
now is a mistake. It's a convenient fiction that htey are
URIs
timbl: I agree from the point of view of XML processing, you can treat them as strings, however the fact that they're separated from the URI spec (that you shouldn't derference them) is wrong
noah: I'd have said there is a resource with many spellings. There is an XLink spec that defines a namespace. Per the webarch, that resource has a number of spellings. But we're going to restrict it further and say that we're only going ot recognize one of the legal spellings.
timbl: first, I'd note that they picked a C14N name, but whether or not they picked a C14N processor would work fine
Some discussion about how a C14N processor would introduce both some rejected documents and some documents where the namespaces changed
ht: we should consider pointing out that many different forms of the IRI for this namespace will retreive the representation (if you choose to provid eone) but only the one that is cahracter-for-character identical to the one listed will match the namespce
Roy: I don't have any problem with the
namespace spec requiring C14N but I do have a problem with
it requiring that one *not* be used
... C14N produces a detectable syntactic error where the
current spec only has a semantic problem
ht demonstrates the problem with two URIs that are the same after C14N
noah: I thin specs should separate definition
of a language from what processors must do
... the XML spec has a history of mixing those notions
ht: I'm still not clear if the followin gproposition is acceptable
<Roy> I don't have any problem with the namespace spec defining simple string comparison for the validation process. I do have a problem with it requiring that C14N not be done, since that interferes with the proper detection of errors in content.
ht: proposition: the example I gave above is a namespace well-formed document.
Not just that this is what the spec says, but also that it is reasonable for it to continue saying that
Roy: I agree that it's a namespace well-formed
document, but that's a user error
... at some point in the process we have to allow tools to
tell the user that it is an error
noah: but the way I'd do that is with another spec that has a different name
ht: I'm happy to suggest to the Core WG that they should add a statement along the lines of "users should not use different spelling of the same URIs in the same document"
timbl: how about defining another term in the
document, "URI C14N well-formedness", that is (a)
well-formed and (b) all the IRIs are canonical
... If they are all C14N then it's C14N well-formed.
noah: the other thing that occurs to me is
that there are specs that build on this spec
... the fact that you can do this means, for example, that
you should be able to build a query system that can
distinguish between them
timbl: IRI canonicalization is something that
should be in QT F&O
... It should do the scheme-independent IRI
canonicalization
ht points out that we should be using the word "normalization" not "canonicalization"
ht quotes from the IRI spec
describing the rules for normalization
(for syntax-based normalization)
beyond that is scheme-based normalization
roy: you can do more and more and more
normalizatoin to narrow the semantic errors
... no matter what you do, if a user creates content that
looks like the bogus example, it will be a semantic error
eventually
... as long as namespaces document says that [the example
of differently spelled equivalent URIs being used in two
xmlns attributes] is valid and correct and not an error,
it's wrong. It needs to allow for semantic errors to be
detected.
... The namespace doesn't restrict itself to a particular
process of valdation
timbl: this spec needs to do two things,
define a syntax and then for something that conforms to
that syntax it defines in some sense the meaning
... at this very low level, the syntax is just the xmlns:
stuff
... the syntax is namespace well-formedness. for things
that are namespace well-formed, it defines the
interpretation of the document
noah: I think that's in the Infoset rec
... it has a particular grammar, so there are things that
are defined with non-terminals, so some specs may build
directly on that
ht reviews the conformance sections of Namespaces 1.1
timbl expresses some concern about the phrase "a processor must report violations". Some processors don't want to report things.
Vincent: Let's try to conclude on
IRIEverywhere-27
... certainly there's something to do here
... I heard two proposals: one is just an addendum to say
good practice is not to use two spellings
... and one which has more to do with changing the spec
ht: I think Core will likely accept, first to say that you shouldn't take advantage of this loophole, and second to change the language so that it's clear that it only applies to the process of doing a particular validation comparison
Roy: the definition in Namespaces 1.1 is
currently contradicting the IRI spec and the IRI spec
wins.
... it's currently an error whether the W3C chooses to fix
it or not.
... I want it to make clear somewhere that all of the
examples in 2.3 do not actually represent different
namespaces. They are distinct names.
<scribe> ACTION: HT to with Norm to report the Namespaces/URI/IRI discussion to XML Core [recorded in http://www.w3.org/2005/09/21-tagmem-irc]
<Zakim> timbl, you wanted to say that we should encorage the use of canonical forms, asking core to define a iri-normalized namespace well-formed document.
<Zakim> tim2, you wanted to talk about relative URIs
timbl: encoding, for example, a SOAP query to
a service. If there are namespaces that are local to the
service, then they could be a lot shorter.
... saving kilobytes of space
Norm suggests that that particular can of worms can't be reopened
<timbl> Tim agrees to leave it as an architectural bug left untouched
+DanC
<noah> > 7 Feb discussion
noah: A lot of this happened before I joined
the TAG. The last status change was 7 Feb 2005, see URI
above
... I thought Stuart was going to take the lead
Roy: should I do this? I fed a lot of text to Stuart before
Norm: I think we should do this still
Roy: there are a couple of other related
things I'm already on the hook for
... I'm hopefully just about to breach the surface for the
first time in 6 months
Roy and Noah will work it out
<scribe> ACTION: RF to and Noah to make progress on metadataInURI-31 [recorded in http://www.w3.org/2005/09/21-tagmem-irc]
Roy: close it
Norm: +1
... xml:id Version 1.0 is a Recommendation
RESOLUTION: to close xmlIDSemantics-32, since xml:id Version 1.0 is a Recommendation
VQ: about mixing XML languages; basically
compound documents
... we now have a working group working on it
Norm: We're going to have to review the CDF work, let's leave this open until we do
Danc: we should make sure we review their requirements
<DanC_lap> > CDF requirements
DanC attempts to nominate timbl to review it
timbl attempts to include noah
timbl: this is related to Noah's presentation of Avalon
DanC summarizes the issue; UI means "documenty"
<scribe> ACTION: TBL to review CDF requirements and report back [recorded in http://www.w3.org/2005/09/21-tagmem-irc]
<scribe> ACTION: NM to review CDF requirements and report back [recorded in http://www.w3.org/2005/09/21-tagmem-irc]
Some discussion of what answer timbl might have in mind
ht: points out that this issue is hugely
complicated at the moment at the coordination level
... there are lengthy, incompatible "best practices"
documents out there
<DanC_lap> > Minutes, 16 September HypertextCG call (Schema special edition) [member confidential]
ht: Schema/RELAX NG/NVDL all play into
it
... NVDL is an attempt to say how to split out a
multi-namespace document and validate the separate parts
<DanC_lap> > my work confirming that mathml/html/etc can be combined using XSD
timbl: suggests that it's unreasonable to try toslve this problem with multiple schema languages. write the schemas in the same language
Norm/Noah suggest that sometimes it might make sense
Norm points out the MathML in DocBook example
Vincent tries to pull us back to the topic at hand :-)
VQ: not very clear from the issues list
Norm: I think the XML Processing Model charter has part to bear on this, suggest that we leave it open for now
We'll leave it open for now
VQ: in May 2005, Roy reopened the issue with
<Norm_> > msg from Roy May 2005
Roy: there was general agreement that the
summary is accurate
... the next step is to do a finding
DanC suggests we could just say the mail message addresses the issue
scribe: or update the existing finding from whence this came
<DanC_EDI> > Authoritative Metadata TAG Finding 25 February 2004
Roy: I think it makes sense to update that finding
<scribe> ACTION: RF to update Authoritative Metadata finding to include resolution of putMediaType-38 [recorded in http://www.w3.org/2005/09/21-tagmem-irc]
VQ: last action was in Feb 2003
... where are we?
DanC: Nothing much has changed, or we could
ask the Sem Web Best Practices WG
... the question here is if I say "x is a car" and someone
else defined "car", have I agreed to his definition?
... suppose that schema document also says things about
other resources?
... if it expresses political views, do I also agree to
those views as well as the definition of car?
noah: I would have thought that I understood the risk, even if I didn't agree
timbl extends the example to say ask what happens if the definition of car is extended to refer to the tax code
scribe: the tax code is defined in terms of the law of the land, its constitution, etc.
timbl: now what happens if someone says I have
a car and also says that democratic forms of government are
evil
... now if you say you want to buy a car, by extension you
could be held to have those beliefs
... there's no well-defined way to extract the definition
of car from the pile of knowledge
Vincent: thanks for the clarification
... so a possible action would be to go to SWBP WG?
This issue was discussed at http://lists.w3.org/Archives/Public/public-sw-meaning/
Roy: if we could go to someone to produce a definitive question, that would help
DanC: we could also ask the world if it's ok to withdraw this
timbl: or we could defer it until we've done a whole lot of basic SemWeb architecture stuff
General agreement to leave it open for now
<scribe> ACTION: DanC to notify the SW CG that we talked about rdfURIMeaning-39 and didn't decide to do anything now [recorded in http://www.w3.org/2005/09/21-tagmem-irc]
VQ: waiting on Roy's actoin
<scribe> ACTION: RF to draft something on URIGoodPractice-40 [CONTINUES] [recorded in http://www.w3.org/2005/09/21-tagmem-irc]
VQ: last event was at f2f meeting, May 2004
dorchard: XInclude was told that it was using
fragids incorrectly and I didn't understand why
... this may also bear on the processing model
ht: I think this connects up to the question
of internal links in HTML documents transformed by XSLT in
the browser
... if it's retriving the HTML, there isn't any
... if it's retrieving the XML, then it should find the XML
anchor and do something with it
noah: in fact the stylesheet may have constructed new anchors
timbl: in this case, and a lot of other cases, the only really consistent rule seems to be "after all the xml functions have been resolved"
dorchard: if it's after all processing, then I
think XInclude was doing the right thing
... XInclude was performing it after processing
timbl: the self describing nature of documents is very important
dorchard makes an assertion about a processor's context
DanC: pointers to doc1.txt#xyz should refer to the same thing, regardless of where they came from
<Zakim> noah, you wanted to ask about arch doc instructions on fragid interpretation
there is disagreement about that assertion
timbl: the point I wanted to make is that it's
important that there be a definitive, single thing that you
do if you're just given a document.
... the meaning of the document must be shared by all
parties
... that's the way it is today
noah: i'm trying to ground this in what the webarch says in 3.2.1
<noah> Webarch 3.2.1 says: "The Internet Media Type defines the syntax and semantics of the fragment identifier (introduced in Fragment Identifiers (§2.6)), if any, that may be used in conjunction with a representation."
noah: henry gets an XML document and he wants to style it with an XSLT stylesheet
<DanC_EDI> (interesting... timbl's privacy policy xinclude example shows this is pretty much the same as rdfURIMeaning-39 )
noah: it's going to produce HTML that has a
set of IDs in it
... now he clicks on a link in the HTML, what's licensed to
happen
... the media type was application/xml
<DanC_EDI> (has the meeting agreed how long this issue list cleanup item should take?)
noah: there are two ways that the spec for the
media type could have been written: one says I only refer
to the XML; another is that I could have said that if
there's a stylesheet PI, then you must transform it and the
correct interpretation is in that which results from the
transform
... the media type spec could say all manner of things
Norm: i agree that the media type spec could have said that
noah: but I'm saying the media type spec wins
Norm: Yes, but I think that's problematic.
<DanC_EDI> (why is the case of no media type spec interesting?)
<DanC_EDI> tim, XSLT does have an output media type mechanism
<Zakim> ht, you wanted to offer an alternative (more conservative?) story about what processing you should do before interpreting fragids
<DanC_EDI> > XSLT section 16 Output, including media-type attribute
ht: (on whiteboard) we have an XML document with a stylesheet PI. The XML includes <loc href='#a'> and <div id='a'>. And the stylesheet produces <a href='#a'> and <a name='a'> when it's transformed
<timbl> This is all a problem stemming from the inadequate architecture around PIs which are kludges.
Norm suggested that it created a new document with a new media type
<DanC_EDI> how would this be any less of a problem if the stylesheet PI was an element or an attribute, tim?
<noah> I think another interesting case is if the user agent used a heuristic, rather than anything in the retrieved document, to decide to apply a stylesheet.
<noah> I'm tempted to say that this last example is the one that will teach us most.
ht: timbl advanced a position which said that there should be a story about what the default processing should be and that's what you should resolve the fragid against. I think I would offer an alternative which is that if a UA has performed a set of processing based on the signals in the doucment, then it should be allowed to interpret the resulting fragids against the transformations it's produced. It's coherent and we should be allowed to say it's coherent to say
scribe lost the end of that
<DanC_EDI> my wish for this issue is that the xinclude text/plain->xml example and this links-in-style-result examples are presented in some document, if only to clarify the questions
<Zakim> timbl, you wanted to note that if XSLT is to be used for this purpose, then it has to be able to output an Internet media Type paired with a representation.
<DanC_EDI> > XSLT section 16 Output, including media-type attribute
Vincent: there's no clear conclusion here
Roy: the actual text in the URI specification
doesn't have any issues having to do with this
... read 3.5 of the RFC for the actual definitions
<DanC_EDI> (sounds to me like all this can be answered in the xml media type spec)
Vincent: I don't see anything to decide now
timbl: we need to argue about it more
Vincent: There are two more issues, let's spend not more than 15 minutes to review these issues after lunch
Adjourned for lunch
<DanC_EDI> what's all this about having no spec for the XML media type? I just followed my nose thru iana and ended up at RFC3023
<DanC_lap> Scribe: DanC
<DanC_lap> ScribeNick: DanC_lap
scribe for Thu AM: DO
discussion of start time for tomorrow... 8:30 or 9am?
seems to be 9am, and HT will accomodate you a bit earlier
VQ: we discussed this at the June ftf...
(what is it that's so out of date?)
DO: WSDL WG asked...
> [Fwd: simple case of IRIs for Components in WSDL 2.0] (abstractComponentRefs-37 )
http://example.org/TicketAgent.wsdl20#xmlns(xsTicketAgent=http://example.org/TicketAgent.xsd)
wsdl.elementDeclaration(xsTicketAgent:listFlightsRequest)
<timbl> oooops sorry
should be http://www.w3.org/2005/08/sparql-protocol-query#SparqlQuery
discussion of multiple symbol spaces in WSDL...
<Zakim> ht, you wanted to talk about language definition
<noah> a?
DO: the TAG already told the WSDL WG this is OK; we had a chance to advise against this and didnt
DanC: I have always argued that multiple symbol spaces are trouble. At least we should encourage the use of barenames and unambiguous local names
HT: I don't think so
<timbl> PERSON_TITLE
<timbl> BOOK_TITLE
HT: there are [10?] cases in HTML where
there's an element and attribute with the same name
... I've [considered? advocated?] a pattern where symbol
spaces are mapped into uri space a la concat($targetNS,
"element", $elementName)...
... but even that doesn't allow for the difference between
title elements on books vs. title elements on [what was the
other one?]
... as we discussed in June in Cambridge, there are
different targets for naming...
... schema and WSDL WGs have targeted specific components
arising from particular defining documents, and Dan was
targeting "the p element" sort of independently of
definition document
<noah> > Henry's note on that to TAG working group
<noah> > Similar note from Henry to the Schema IG List (member-only)
HT: I'm not happy starting with the notion
that [something?] is a function of namespace,
sort/symbol-space, and localname. I'd prefer to start with
the notion of language, where a language may include terms
from multiple namespaces...
... ... and I think the case of not using namespaces should
be on the same footing. As well as the case where languages
change namespaces between versions and those that change
versions without changing namespaces. I'd like to tell a
story about non-XML languages, e.g. css
... it's not clear that we have URIs for CSS
properties.
... and we should
... my thinking:
... (1) a language is set of versions
... (2) a version is (primarily) a mapping from sorts x
names (x definition language?) => definitions
... and one of the things a definition should have is a set
of versions for which it's valid
... what I don't have a clear answer to yet is: who's on
top?
[?]
<Zakim> timbl, you wanted to disagree with the non-ns languages having URIs without magic., and to mention the idea of default namespace URIs by mime type
TBL: yes, a language is a good thing to
define. Let's keep version separate: a language is a
grammar and corresponding definitions...
... I'm less inclined to give URIs to things that don't use
namespaces [that's what he said, but I can't imagine it's
what he meant].
... I am interested to connect default namespaces to mime
types, a la "the default namespace for this media type is
XYZ"
... so yes, the XML parser would get another parameter,
similar to base URI
HT: grandfathering namespaces in conflicts
with deployed XSLT stylesheets
... I'd like to have a URI for "the p element in docbook",
where docbook has no ns
<Zakim> DanC_lap, you wanted to comment on not using namespaces
TBL: no I; I'm happy to [something]
<DanC_> > webarch good practice note on using namespaces
TBL: no, I'm happy to let namespace-less languages left behind, if it hurts the architecture to bother with them
DanC: indeed, the webarch REC says you SHOULD use namespaces.
HT: so... is this language/sort/definition stuff something the TAG is interested in?
DanC: yes, but the burden is on you to argue that we should bother with namespace-less docs
TBL: language definitions can only sometimes be decomposed into separate a separate definition of each term
HT: I expect these definitions ground out in traditional specs.
TBL: in RDF, the semantics is that the meaning of the document is the conjunction of the meanings of the statements, but other languages are more complicated than that
<Zakim> DanC_lap, you wanted to say there's lots of stuff besides sorts
HT: I don't claim that this sum of the 'semantics' of all the names gives you all the information about the document.
<Zakim> noah, you wanted to talk about compound document example
<Zakim> ht, you wanted to express nervousness about encouraging a simplistic view
DanC: I think sort/symbol-space is one of many qualifiers... but meanwhile, in many cases, namespace#local-name is good enough, and we should encourage it
HT: I don't think the simplistic view of
namespace@local-name is something to encourage; I think
it's misleading.
... e.g. no Java programmer would accept package#localname
as a way to refer to java classes, since there are multiple
symbol space
<ht> HST likes the idea that if there is only one sort of thing in a language, the cost of allowing for multiple sorts in other languages should be zero
NM: I'm sympathetic to the idea of using namespace-name#localname for languages where that works, but I don't like it as short-hand. I like one name construction idiom for each language.
<Zakim> timbl, you wanted to point out that the fact that that XML has complexities which are used in most cases is a problem.
TimBL: I think it's worth pointing out that a
single symbol space has its advantages
... and I like a simple prefix mechanism consistent with
fragment identifier syntax, e.g. p_ for wsdl ports
<noah> Dave and Henry ask: why not use "/"
<noah> TimBl answers: because I want to do this in a fragid
DO: so why p_ rather than what WSDL does...
(missed some stuff about whether you need a new media type, or just a new xpointer scheme, or whatever)
NM: with the xml media type and XPointer, you
point to element information items, not WSDL interfaces
etc.
... right?
HT: right; I don't think anybody's arguing for using straight xpointer/xml...
<timbl> http://en.wikipedia.org/wiki/Metonymy. In rhetoric and cognitive linguistics, metonymy (in Greek meta = after/later and onoma = name) is the use of a single characteristic to identify a more complex entity.
DanC: some of the response to my comment to WSDL seemed to be arguing for just existing xpointer
NM: an xpointer scheme can resolve to things other than the markup [infoset], right?
HT: I think I convined Makoto otherwise, so we should check the next draft
<Zakim> Norm, you wanted to point out why xpointer schemes are easier than mime types
<ht> Tim's shorthand proposal (e.g. e_person for 'thing with name person of sort e...' requires a new media type to specify the parsing of the fragid wrt _
NDW: the advantage of a new xpointer scheme over media types is... [scribe didn't get the point and it seemed to disappear]. Xpointer has fallback.
<ht> The new-XPointer WSDL approach requires registering a new xpointer scheme
<ht> HST claims that unknown-media-type fails much earlier in the stack than unknown-XPointer-scheme, with the consequence that it's easier for mere mortals to add support for new XPointer scheme than for new media type
DO: I'd like HT to look at his languages story w.r.t. the draft finding on versioning with the UML diagram.
HT: yes...
<Zakim> DanC_lap, you wanted to re-state my original proposal
DanC: It should be standardized that target-ns#SparqlQuery refers to the sparq interface
<ht> http://www.w3.org/2003/10/06-tag-summary#abstractComponentRefs-37
<Norm> http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0075.html
<Norm> http://airline.wsdl/ticketagent?wsdl;wsdl-interface=TicketAgent
from last call WSDL 2:
<DanC_> > component ref section of WSDL 2.0
<dorchard> > Oct 2003 draft on abstract component refs
<dorchard> "As for the particulars of the syntax, the TAG does not wish to delve into syntax design of the WSD fragment identifier syntax, believing that the WSD WG is better qualified for such activities. Members of the TAG did express support for Option 1 in the Namespace name and fragment identifier syntax section, but this is not a consensus opinion and the TAG plans no further elaboration on the WSD specific syntax"
<Zakim> ht, you wanted to point out the W3C TR policy parallel, which calls Noah's and my understanding from June into question
[scribe has gotten too involved in discussion to scribe much]
<ht> HST now thinks that HTML P is an example of hard cases make bad law
yes, to some extent, henry
<Zakim> DanC_lap, you wanted to ask if "Dan's problem" is really just "Dan's problem"? isn't it the more typical case of how URIs work, i.e. something very architectural? you can find out about doc#term by deferencing doc and looking inside, but you might also find out from other parts of the web; but the info from other parts of the web really shouldn't disagree with doc
<Zakim> timbl, you wanted to compare Henry's generic lunch protocol with a generic resource which has many translations and versions.
noah, I don't know about "which is more important", but I think it's a bug, w.r.t. web architecture, if documents disagree about what other documents say.
scribe: and so we shouldn't encourage URIs for "what doc1 says, according to doc2". "what doc1 says" shouldn't need to be qualified.
<ht> HST recalls that last week we observed that wrt Dan's example, for "the way normal URIs work", that the Wayback machine gives you a way to be clear about a particular 'edition' of the lunch protocol
<Zakim> ht, you wanted to query TBL about that
<Zakim> ht, you wanted to ask about the single namespace doc't bug???
(... resuming from break ...)
HT: seem to be 2 things: (1) what info you need in the URI (2) how you package them up
DanC: take (a) "must map qnames to URIs" and (b) URIs should be unambiguous; put those together, and there should be an unambiguous URIs for the SparqlQuery interface
NDW: so they gave you a mapping; you don't like it?
DanC: they didn't give me a mapping irrespective of WSDL doc addr
<timbl> [timbl wonders whether DanC meant "unique" rather than "unambiguous" ]
<ht> > a photo
<scribe> ACTION: DanC to seek clarification about http://example.org/TicketAgent.wsdl20#wsdl.interface(TicketAgent) [recorded in http://www.w3.org/2005/09/21-tagmem-irc]
<DanC_> note to self: including .wsdl20 extension in the namespace URI was distracting... and parens are inconvenient to use in RDF.
HT: there may be an intermediate position...
stipulate that Xpointer scheme registration opens...
... that a scheme might refer to namespace bindings from
the document [?]
<Zakim> timbl, you wanted to * opening XPointer registration
HT: let's talk about xpointer scheme registration under 3.11 Issue standardizedFieldValues-51
DO: this seems to make 2 cases where you can use namespace bindings indirectly... there was that ws-addressing thing yesterday[?]
TBL: can one get a WSDL description from a service by a GET on the service URI?
DaveO: the WS-[which?] spec has a Get[something] request that gives you [a pointer?]
VQ: conclusions?
DO: there's the action on DanC, then we'll consider updating the 37 finding or the finding on good URI practices
<DanC> [which is good enough for me]
<timbl> Talking about making URIs self-bootstrapping. Suppose you have a URI which is a qyery on a service. The query part has qnames which use prefixes from the WSDL document. How do you find the WSDL document? You do a WS Metadata Request call to the service. That indirectly gets you to the WSDL.
<timbl> Roy, if the fragid is of the form of an XML local name, then the URI gains usability in that it can be writen as a qname in RDF.
RF: depends on whether xmlname is unambiguous, so I may need to write more than just one sentence
TBL: this is something that helps users of URIs, i.e. those that write them in documents that refer
<scribe> ACTION: RF to consider noting in finding on good uri practices that gooduri#xmlname is a useful pattern because it can be used easily in RDF [recorded in http://www.w3.org/2005/09/21-tagmem-irc]
(yes, please let's have pointers to the current draft)
<noah> David Orchard email announcing revised drafts
> part 1
DO: I started updating a draft finding, and got some comments from noah, and it turned out that the terminology is not settled, and it's hard
<DanC_> [figuring out the terminology _is_ the problem. ]
<Zakim> DanC_lap, you wanted to suggest re-constructing the UML diagram collaboratively
