W3C home > Mailing lists > Public > www-tag@w3.org > January 2006

Draft minutes of 3 January 2006 TAG teleconference

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Tue, 03 Jan 2006 15:07:43 -0500
To: www-tag@w3.org
Message-ID: <87lkxx848g.fsf@nwalsh.com>
The draft minutes from today's telcon are now available:

  http://www.w3.org/2001/tag/2006/01/03-minutes.html

Text version follows:

W3C

                                   - DRAFT -

                           TAG Weekly Teleconference

3 Jan 2006

   Agenda

   See also: IRC log

Attendees

   Present
           DC, HT, ER, NM, NDW, TBL, VQ, RF_(arrived_late), DO_(arrived_late)

   Regrets

   Chair
           VQ

   Scribe
           Norman Walsh

Contents

     * Topics
         1. Approve minutes of 20 Dec
         2. Next telcon: 10 January
         3. Accept this agenda?
         4. namespaceState-48
         5. Issue namespaceDocument-8
     * Summary of Action Items

     ----------------------------------------------------------------------

   <Norm> Scribe: Norman Walsh

   <Norm> ScribeNick: Norm

   Date: 03 Jan 2006

   <DanC> hmmm... I have ht's "What is a namespace, anyway?" message flagged
   for response... would be nice to have one or more issues connected to it
   for prioritization

   I would guess it's related to nsState-48 and perhaps the whole "grounded
   in the web" issue of self-describing documents that ht and I still have
   open.

   Hey, timbl, I sent you something about that before Christmas, did you ever
   get a chance to read it?

   <DanC> I think you'd rather I *didn't* associate it with nsSate-48, right,
   ndw?

   <DanC> Vincent, I see actions re issue 8 still in
   http://www.w3.org/2001/tag/2005/03/action-summary.html and not synced with
   the issues list

   <ht> Well, I have to confess that email
   (http://lists.w3.org/Archives/Public/www-tag/2005Dec/0120.html) did start
   from our discussion of nsState-48 last time . . .

   <noah_montreal> +n5c2 n6ah

  Approve minutes of 20 Dec

   They looked fine to me

   ER: They looked fine to me too

   RESOLUTION: Approved

  Next telcon: 10 January

   No regrets given

   <DanC> minutes 20 Dec (1.2 2006/01/03 18:05:15)

   RESOLUTION: Confirmed; DO to scribe, ER in his absence

  Accept this agenda?

   DC: Related actions pointers to go the issues list
   ... As far as I can tell, the old pending list still has novel information

   VQ: I've made progress on the issues list but the actions are not yet
   up-to-date
   ... The only complete action list we have is still the separate small
   list.
   ... I'm still planning to move everything to the issues list.

   RESOLUTION: Agenda accepted

  namespaceState-48

   NDW proposed http://lists.w3.org/Archives/Public/www-tag/2006Jan/0007.html

   <DanC> looks good... [[ An XML namespace has a namespace name (a URI) and
   a set of local

   <DanC> names (NCNames as defined in [XML Namespaces]). ]]

   NDW: That's what I came up with from the minutes

   HT: I can live with it, but I'd like to see if we could live with more.
   ... I wondered if we have consensus about what the namespace name
   identifies.
   ... Sometimes I think it identifies a set of names and sometimes I think
   it identifies a namespace. Since we don't have a good definition of the
   latter ,that's not helpful
   ... Suppose I said: "A namespace is identified by a namespace URI (aka the
   namespace name)" Would that attract consensus.

   DC: It's tautologically true, but not useful

   <Zakim> timbl, you wanted to say that there is a pun going on: the ns uri
   is a string and a URI of a document

   HT: I'd like to find an answer to the question "what is identified by a
   namespace uri" in the webarch document.

   TBL: The namespace URI identifies a namespace document. The namespace
   doesn't have a URI; it's a set of names which start with this common
   prefix which is kind of a string.
   ... It's a little architectural kludge. It happens to be the same URI used
   for all the names, but it identifies the namespace document.
   ... You could have a separate URI for the namespace, e.g.,
   namespace-document-uri#thisnames, but it's not really worth doing
   ... Maybe we should be able to talk about namespaces in the abstract, but
   we don't very often.

   NM: I

   <Zakim> noah, you wanted to remind ourselves that we should decide whether
   we're talking specifically about namespaces in XML

   NM: I've been troubled about our lack of clarity about when we're talking
   about namespaces in XML (a W3C Rec) vs. namespaces in a broader sense
   which almost certainly include namespaces as used in RDF in the abstract
   which are often serializeable in XML and could go on to include anything
   on the web that feels like a structured namespace.

   <noah> [Definition: An XML namespace is identified by an IRI reference;
   element and attribute names may be placed in an XML namespace using the
   mechanisms described in this specification. ]

   NM: I understood the history of this issue to be largely about Namespaces
   in XML.
   ... I'm happier just to avoid scope creep and keep this finding focused on
   namespaces in XML.
   ... This issue started by raising the question "gee, we've got these XML
   namespaces (specifically the xml: one), and some folks think they're
   mutable and some don't and we need to say something about that"
   ... I think we've all agreed with NDW's analysis. I don't think we should
   go very far in restating or bending what the recommendations say about
   what the URI identifies or anything else.

   <Zakim> DanC, you wanted to say that I prefer not to dereference (use)
   namespace names; I prefer to combine them with localnames to come up with
   a URI-term and look that up and to note

   DC: If you're happy with NDW's text, then we're fine. If you're saying
   namespaces in RDF are different than namespaces in XML, then I object.

   NM: I don't think we need to go there for purposes of this issue.

   <ht> HST wonders why the httpRange-14 compromize isn't the right way to
   approach the identifies a namespace/a namespace document issue . . .

   TBL: The TAG document says that this URI identifies the namespace
   document. Now we've got this recommendation that says "identifies this
   namespace". One way out is to say that it's indirect identification.
   ... You can say that the namespace is the one that has that namespace
   document, for example.
   ... We can weaken the sense of "identifies" in the namespace document.

   <noah> I agree with Tim that there is some issue as to whether the URI
   should identify the document, the namespaces, or perhaps the document as
   representative of the namespace. What I'm quesitonning is whether we need
   to go into any of that in order to resolve >this< issue.

   <ht> "namespace URI can be used to identify an information resource that
   contains useful information,"

   <Zakim> noah, you wanted to say HTTP range 14 doesn't talk about
   documents, it talks about info resources

   DC/TBL discuss where this is actually grounded in the webarch document

   <ht> http://www.w3.org/TR/webarch/#namespace-document

   NM: The httpRange-14 resolution talks about info resources not documents

   TBL: Do you really want to go there?

   NM: My definition of an information resource leaves open the possibility
   that our httpRange-14 resolution allows me to return 200 for the namespace
   document. I think they fit well in a computer message.

   TBL: Informally, we mean "document" when we say information resource

   NM: Information resource is either a synonym of document or very close

   TBL: Yes

   VQ: I'd like to separate nsDocument-8 and namespaceState-48. Can we reach
   a conclusion about 48?
   ... We can let the discussion about namespace documents go to the next
   item.

   <timbl> I am happy with the text.

   VQ: To me the last issue that was relevant to the finding was just this
   first paragraph. NDW has rewritten it, I have heard several people
   agreeing with (or satisified with) what NDW has drafted. Can we focus on
   that paragraph?
   ... Does anyone have a problem with it?

   <Roy> link?

   DC: I'm happy with that paragraph but I have another comment

   <noah> No problem with Norm's proposed text.

   VQ: Is there consensus on NDW's para?
   ... Yes, I conclude that there is.

   DC: The good practice suggests that it's OK not to have it in the
   namespace document. That seems bad.

   NDW points two paragraphs done.

   DC: Can we combine the two shoulds into one.

   <noah2> +1 to separating them

   HT: No that's weaker because it says if you don't have a namespace
   document you're off the hook.

   <Roy> s/namespace name and a local name, the qualified/namespace name and
   a local name: the qualified/?

   DC: Yes, you're off the hook but in the doghouse.

   NM: I agree with HT and NDW.

   <EdR> I like it the way it is.

   VQ: I guess we can keep the document as it is for that part. Ok, DC?

   DC: Yeah.

   VQ: Any other comments?

   NDW makes the change RF suggested

   <DanC> (ndw, can you save to
   http://www.w3.org/2001/tag/doc/namespaceState.html )

   <EdR> +1 to approve now

   NDW: Proposed: approve NDW's namespaceState-48 finding with the new
   paragraph and the editorial suggestions proposed by RF and NM as an
   approved TAG finding.

   <DanC> 2nd

   <Roy> +1

   VQ: Anyone object?

   RESOLUTION: the proposal carries

   <scribe> ACTION: make the changes, publish the finding, and post to
   www-tag [recorded in
   http://www.w3.org/2006/01/03-tagmem-minutes.html#action01]

   DC: Who's waiting for this?

   NDW: Core was waiting, but since xml:id has already gone to REC...

   NDW promises to dot the i's and cross the t's wrt XML Core after he's made
   the announcement

   DC: I wonder if there's anyone else that cares

   DC asks about xml:base

   NDW pushes back successfully.

   NDW: The problem with mentioning xml:base is simply that it would cause
   more editorial changes than I'm comfortable making after we've approved
   the finding :-)

   <noah> scribenick: noah

  Issue namespaceDocument-8

   NW: I noticed last time that the examples were bad and that the appendices
   were confusing people.
   ... The 13th Dec. draft more carefully uses the actual RDDL namespaces for
   natures and purposes.
   ... I've also added the list of RDDL natures and purposes to sections 5 &
   6. BTW: those sections are therefore no longer blank.

   Noah also thanks Norm for adopting some of his more minor suggestions.

   VQ: Who else has reviewed this?

   NM: I've reviewed the lastest and I'm quite happy with it.

   RF: I've skimmed.

   <Norm> RF: there's not really an example of a namespace that isn't flat in
   nature

   <scribe> scribenick: Norm

   RF: I suggest mentioning a namespace where the namespace isn't flat

   DC: Clearly HTML is in that space. Constructing a namespace document for
   HTML would be much harder.

   RF: I don't have a better example in mind

   DO: Do you mean something like WSDL that has symbol spaces?

   RF: I was thinking of XML documents where there'd be a link element named
   "a" and some other element with an attribute named "a"'

   TBL: Isn't that what you meant?

   DO: Yes

   HT: I can't think of any that are as well know as HTML that have an
   example of this

   DC: I think it'd be great if it wasn't quite so well known.

   TBL: Should we as the TAG say that this is a bug. These things aren't
   universal names.

   <Roy> and also the case where the element (e.g., <address>) means
   different things depending on what elements encapsulate it.

   DO: How are they not universal if the fragid specification tells you how
   to make the names?

   <Zakim> noah, you wanted to suggest that deprecating symbol-space-like
   constructs is its own issue, not a no brainer

   TBL gives the example of "cite" in HTML meaning either the element or the
   attribute

   NM: I don't think that this example is sufficiently obvious or
   straightforward that we want to slip it into this finding. Maybe this is a
   good new issue.
   ... I think there's a lot to discuss before we get there.

   DC: I don't think you need to split the issue.

   NM outlines why he thinks its a different issue

   NM: I think your critique is about the nature of the namespace not the
   namespace document

   <ht> Well, the schema for schema documents has two distinct element types
   whose local name is 'group', and that name also is used for an identity
   constraint

   DC: I think a lot of folks won't be a happy if we close this issue without
   addressing this issue

   TBL: we should point out that there are cases where the names aren't
   universal and maybe point to another issue.

   NM: That's what I was saying. It's too big to go in a namespace document

   <Zakim> Roy, you wanted to suggest adding an algorithmic mapping of names
   to URIs within the RDDL document

   <noah> Actually, I said it's beyond the scope of this >issue<

   DC: I'd be happy just ot not close any of these issues until we close the
   "self describing documents" issue.

   <ht> I would have said 'not unique' or 'not unequivocal' rather than 'not
   universal'. . .

   <noah> as this issue is about Namespace Documents, not the design of
   namespaces themselves.

   RF: I'd suggest that this is one of those places where we can address the
   question independently of various opinions about what's an appropriate
   namespace. A lot of these things already exist. I'd rather have a way to
   say "if you need to know the URI of something" then here's how to do it.

   <noah> Therefore, I would prefer to open a new TAG issue on whether symbol
   spaces are or are not bad practice. I don't think we have consensus to say
   that here, and I think that in any case doing so would be beyond the scope
   of this issue.

   RF: I'd rather point to a namesapce document that describes an algorithm
   for doing the mapping
   ... For example, in a flat namespace it could be concat(uri,'name'). There
   are lots of ways (editorially) that this could be expressed.

   TBL: For a more complex example, I guess we could point to the WSDL case.

   <Zakim> ht, you wanted to ask Roy about expressing sorts in URIs via path
   components vs. via parameters

   <ht> i.e. .../1999/xhtml/element#cite vs.
   1999/xhtml/?sort=element&name=cite

   HT: Suppose we take one of these example, Roy, do you have an inclination
   about putting the "sort" in the path or the parameter or a syntactically
   complex fragid.

   RF: It's irrelevant to me so what's important is that there be no
   restriction.

   VQ: It's still not clear if we need a new issue

   <DanC> (when TimBL says "cite from HTML" is ambiguous, one possibility is:
   no, it's not ambiguous; it refers to the element. attributes don't have
   top-level names. Another is to say html#cite is indeed a hosed URI; it's
   ambiguous; don't use it. use html#element_cite or html#attribute_cite)

   DO: I think it should be in this finding. It seems awfully darned related.

   <ht> DanC, right -- that's the third (syntactically complex fragid)
   approach

   <noah> My main concern is that we not try to do a rush job on symbol
   spaces. If the group wants to take the time to do a careful analysis and
   see whether it fits well here, I have no objection.

   NDW proposes to make a stab at expanding section 4

   <Roy> +1

   NDW agrees to have it done by 17 Jan

   <ht> DanC, none of the three approaches in their simplest form will cope
   with arbitrarily nested scopes, as in W3C XML Schema (and many programming
   languages)

   <Roy> NDW's proposal

   <noah> Fine with me too.

   DC: I'd rather not try to patch this. I don't want to prempt the stuff on
   self describing documents

   DC expresses concern about the number of hours in the day and the fact
   that NDW is on the hook for self-describing documents

   <Roy> http://www.w3.org/2001/tag/doc/nsDocuments/#div.fragid

   TBL: Are you proposing that we widen the scope

   DC: Yes, let's talk about the whole range of issues related to
   self-describing documents right now
   ... That's the highest priority for me at this point

   NM ponders how we'll structure our time if we do this

   DC: I don't want to add an issue on self-describing documents because it's
   already in so many of our existing issues. We keep dividing ht equestion
   so we can't actually talk about what we need to talk about.
   ... I think the best bang for the buck is to discuss something on shared
   text.

   <noah> I'm surprised. I think self describing documents makes a great
   standalone finding.

   DC: I think ns-8 is responsive as it is.

   <noah> Me too. That's one reason I didn't want to broaden now, as we are
   close to publishing something useful.

   HT: Agrees assuming we add something to the preface about the complexity
   of non-uniqueness.

   NDW ponders calling this fiding finished and doing the same work he
   earlier proposed under a different title

   RF: If the topic comes up again in the future, I think section 4 is where
   the answer belongs.

   VQ asks DC about closing it

   <ht> HST would like the docbook example graph diagram to use 'validation'
   as the purpose of the top two links

   DC: I'm of several minds. It's acceptable to me to try to call it done as
   it is.

   <DanC> <http://www.w3.org/2005/12/assoc#>

   <noah> Should the doc state that this URI is new for purposes of this doc?

   <DanC> 404 there

   DC: I want to point out that 2005/12/assoc# is created by this document.
   The 404 is unacceptable.

   <Roy> It is acceptable to me to call it done for now, but I think the TAG
   should consider adding such an algorithm statement (how to contruct URI
   for each term in my namespace) to NS descriptions and then revising
   section 4 accordingly

   <DanC> (ouch. still finding typos in the examples.)

   In draft finding: assoc:relaxng-validation should be
   purpose:relaxng-validation

   HT: The purposes of both these first two is validation.
   ... In the prose you say "validation"

   NM: I think this leads to a long discussion in which both sides are right.
   ... I can imagine use cases where it really matters that they provide
   overlapping but different services and some use cases where they really
   are the same

   HT: At the very least they need to be made consistent.

   VQ: I hear consensus about publishing the document more-or-less as it is,
   just fixing a few details.
   ... Is there any objection about that?

   DC: And closing issue 8?

   VQ: Yes, and closing issue 8.

   HT: Why is the ontology non-normative.

   NDW professes ignorance in ontology creation

   HT agrees it's tricky.

   DC: Now we're into issue RDF meaning...

   <DanC> rdfURIMeaning-39

   NDW: It's the prose that's normative. The ontology is just an expression.

   DC: asks about following your nose

   <Zakim> DanC, you wanted to recall why we can't close 8 just yet

   <DanC> "DanC to ask for "default nature" to be changed to "implicit
   nature" in RDDL spec"

   HT: agrees you don't find these statements now, but I believe Jonathan
   Borden would add the link if the community agrees

   DC: I thin it'd be nice if App B said "we'd like the RDDL folks to point
   to this"

   HT: I wouldn't mind asking him first. This has been pointed to from
   www-tag several times.

   DC: I have an action earlier, I could add this to that.

   <Zakim> timbl, you wanted to asl whether these nature URIs identify
   natures as URIs.

   TBL: Asks about the nature of natures

   <timbl> http://www.ietf.org/rfc/rfc2026.txt

   <timbl> http://www.iso.ch/

   TBL: Is "http://www.ietf.org/rfc/rfc2026.txt" the nature of an IETF RFC?
   ... Is "http://www.iso.ch/" the nature of an ISO spec?

   DC: In RDDL land, yes. Pretty weird, but yes.

   TBL: So these aren't URIs?

   DC: How do you mean?

   <timbl> http://www.ietf.org/rfc/rfc2026.txt

   TBL: Because ...rfc2026.txt is the URI of an RFC so how can that be a
   nature?
   ... I don't think that's the architecture they're using.

   HT: I think it is fairly parallel to the discussion we had earlier about
   indirect identification.

   DC: So the rddl.org stuff has some waffly prose and such but what this
   finding says is that if you GRDDL it you can believe the RDF. Whatever
   wooliness was in the spec, you can now appeal to RDF semantics. The RFC
   *is* the nature.

   HT: net net: good or bad?

   <DanC> assoc:nature

   DC: Borderline acceptable.
   ... We own 'assoc:nature' so we're saying that the nature of an RFC is an
   RFC.

   HT: That one's a bit of a pun. But take the nature of HTML 4.

   TBL: In all of these where there isn't a hash, I don't like the
   architecture.
   ... In one case it's a document defining a language, in another case it's
   the home page of an organization.

   <DanC> (yes, I was wondering if timbl understood what this finding says.
   I'm glad he's swapping it in, though it does seem to be undoing the
   proposal we almost resolved.)

   TBL expresses concern about the fact that he can't conclude anything from
   the fact that something is a nature

   HT explains how the standard use case works.

   TBL: I think these things are squatting in URI space, they aren't really
   URIs. You can't use the ISO home page without asking their permission.

   <timbl> natureRelatedSomehowTo

   NDW: I can see how it's weird but these URIs are already deployed.

   DC: We could change the mapping. We could create a more complex mapping.

   <timbl> DanC: We could make the RDF say 'the nature is something whioch is
   an org wih this homepage:"

   <Zakim> noah, you wanted to talk about layering

   NDW expresses concern about making the model more complex because it's
   going to make getting community consensus more difficult

   NM: There's a yin-yang thing here, where sometimes a very carefully
   layered ontology is constructed and sometimes "rough and ready" weirdness
   "just works". But at least if I know what I want to put in a RDDL document
   it's the same thing I put in the top of my schema document.
   ... If for each of these 18 things I have to go somewhere to figure out
   how to change it, that makes the problem even worse.
   ... Given that it's deployed and there are operational advantages to just
   leaving it alone.
   ... The same URI is being used for the nature and the beast itself. It's
   not ideal, but I'm inclined to leave the RDDL world alone.

   <DanC> (but we're not leaving the rddl world alone. we're coining
   assoc:nature )

   NM: Each person doing a new one does it their own way.

   TBL: I feel the other way. I'd never want to use any of the RDF statements
   from these RDDL documents in my system.
   ... There may be a large number of people who feel that way now, but I'm
   not willing to put a huge spoke in the reusability of data for this.
   ... I think we should change them all.

   NM: You're impling that by using the URI for ISO here you'd be encouraging
   people to confuse ISO with a nature. But I'd have thought that what comes
   out of here is an RDF predicate. If NDW defines this not as "this is a
   nature" but "this is a resource that reminds you of a nature" I'd have
   thought this would be ok.

   <DanC> interesting possibility... assoc:nature is "a resource that will
   remind you of the nature"

   Scribe fails to capture the point TBL tries to make

   TBL: objects to "remind" because it's hard to see how that would be
   understandable to a machine.

   NM: Proposes a mechanical transformation

   DC: How does that help

   <ht> I still like an anonymous node whose xxx:namedByRDDL1.0With property
   is http://www.iso.ch/

   NM: Formally on the RDF side whenever you are refering to the nature you
   get a URI that isn't the URI of ISO

   TBL: proposes how you might turn all the URIs in to local names.

   <timbl> http://www.rddl.org/natures/

   VQ: At this point we're running out of time.

   TBL: We're in the middle of a conversation.

   VQ: I propose that we get back to this next week but to try to decide how
   to progress. We need to figure out how to organize the work for the
   future.

   <DanC> (tbl, do you consider your action re
   http://www.w3.org/1999/10/nsuri to be relevant to this issue, 8? hmm...
   perhaps more relevant to nsState48)

   VQ: Think about how we can make progress and we'll come back to this next
   week.
   ... We also need to talk about the last call documents from the CDF next
   week.

   ADJOURNED

Summary of Action Items

   [NEW] ACTION: make the changes, publish the finding, and post to www-tag
   [recorded in http://www.w3.org/2006/01/03-tagmem-minutes.html#action01]
    
   [End of minutes]

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

Received on Tuesday, 3 January 2006 20:09:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:38 GMT