- From: Thierry MICHEL <tmichel@w3.org>
- Date: Tue, 14 Apr 2015 05:40:31 +0200
- To: Ivan Herman <ivan@w3.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Ivan,
I had also send my regrets
see
https://lists.w3.org/Archives/Public/public-digipub-ig/2015Apr/0029.html
Please update.
thanks,
thierry.
On 13/04/2015 18:50, Ivan Herman wrote:
> The minutes are here:
>
> http://www.w3.org/2015/04/13-dpub-minutes.html
>
> A text version is below.
>
> Cheers
>
> Ivan
>
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
> [1]W3C
>
> [1] http://www.w3.org/
>
> Digital Publishing Interest Group Teleconference
>
> 13 Apr 2015
>
> See also: [2]IRC log
>
> [2] http://www.w3.org/2015/04/13-dpub-irc
>
> Attendees
>
> Present
> Charles LaPierre (clapierre), Nick Ruffilo
> (NickRuffilo), Bill Kasdorf (Bill_Kasdorf), Heather
> Flanagan (HeatherF), Markus Gylling (Markus), Alan
> Stearns (astearns), Matt Garrish (mgarrish), Ivan Herman
> (Ivan), Peter Krautzberger (pkra), Brady Duga (duga),
> Karen Myers (Karen_Myers), Ben De Meester (bjdmeest),
> Mike Miller (MikeMiller), David Stroup (david_stroup),
> Tim Cole (TimCole), Paul Belfanti (pbelfanti), Bert Bos
> (Bert), Luc Audrain (Luc), Liam Quin (Liam)
>
> Regrets
> ayla, vlad, julie_morris
>
> Chair
> Markus
>
> Scribe
> NickRuffilo
>
> Contents
>
> * [3]Topics
> 1. [4]Aria module discussion
> 2. [5]Packaging examples
> 3. [6]F2F agenda
> 4. [7]identifiers
> * [8]Summary of Action Items
> __________________________________________________________
>
> <trackbot> Date: 13 April 2015
>
> I'm sorry Zakim, but I'm not giving up on you. You'll be a real
> boy soon enough.
>
> <scribe> Scribenick: NickRuffilo
>
> <ivan> scribenick: NickRuffilo
>
> Marcus: "Anyone with objections to approving last weeks
> minutes?"
> ...: "Approved."
>
> Aria module discussion
>
> <mgylling> [9]https://rawgit.com/w3c/aria/master/aria/dpub.html
> ...: "Epub module for ARIA. Link posted in IRC. This was
> discussed in the previous meeting. State is that the editors
> are trying to get it to first public working draft."
>
> [9] https://rawgit.com/w3c/aria/master/aria/dpub.html
>
> <mgylling> minutes are here:
> [10]http://www.w3.org/2015/04/09-aria-minutes.html
> ...: "we need to have a recorded consensus from both publishing
> groups. The protocols and formats working group..."
> ...: "PF discussed the editors job. There were some concerns
> against it so they have not gotten to a public working draft
> yet. We'll be discussing this with them for the weeks to come."
>
> [10] http://www.w3.org/2015/04/09-aria-minutes.html
>
> ...: "Concerns were: Global issue - prefixing of terms for
> modules such that they end up in different domains. Also a
> number of concerns in specific terms, such as the 'abstract'
> term which is well known in books, but also a term used in ARIA
> for a different purpose. Abstract roles are something that
> should never be used for content... Identical strings but
> different meanings."
>
> <Bill_Kasdorf> Just reiterating my minority opinion that I
> think prefixes are very useful. The abstract example is one of
> many.
> ...: "First public working draft isn't expected to be fully
> complete, or without conflict, which is why we hoped to get
> there, but it seems these issues need to be discussed before it
> can get there."
>
> Ivan: "We should see how far we can go and where the
> breakpoints are"
>
> Bill: "A little bit stronger case: I've always thought that
> prefixes would end up being necessary. In real-estate what you
> call an abstract is different from what you call it in
> books/journals. there are scores of examples of definition
> conflicts if we don't use prefixes."
>
> Marcus: "The role attribute DOES have a prefixing for
> definitions"
> ...: "Based on the RDFA way of doing things. Using the :. The
> vocabulary basics..."
>
> Bill: "I was also reminded that despite the fact that it isn't
> used much, the prefixing IS available in the role attribute."
>
> <ivan> role="dpub-blabla"
>
> Ivan: "You say the roll attribute has prefixing using the
> color. But that's the full domain space, etc. That's a sledge
> hammer. I thought that you can do something like '[typed
> above]' is that accepted within ARIA?"
> ... "it's not a dynamic prefix name."
>
> Ivan: "When they're using namespaces, do they want the obvious
> sledgehammer or the dash?"
>
> marcus: "It's highly undesirable to have this."
> ... "Maybe we can raise the question again. If we look at it
> from a 10-mile high up perspective. If it looks like the W3C
> wants to support digital publishing, why should things be
> supported..."
>
> <Karen_> Nick: Coming from a different perspective
>
> <Karen_> …what it sounds like, is we are utilizing certain
> terms
>
> <Karen_> …for what would be ARIA prefix
>
> <Karen_> …abstract
>
> <Karen_> …we were defining a term in relations to
>
> <Karen_> …a given concept with a limited view space
>
> <Karen_> …so an abstract is a conceptual term that has a solid
> definition but limited in its scope
>
> <Karen_> …what might be a good idea, and for future groups
>
> <Karen_> …is to take a step back
>
> <Karen_> …and say an abstract is a specific concept of what
>
> <Karen_> …boil down what abstract is…ultimately a summary
>
> <Karen_> …or ultimately a division
>
> <Karen_> …so take a step back
>
> <Karen_> …we might have 16 different definitions for abstract
>
> <Karen_> …and four high-level concepts that we should define
> terms for
>
> <Karen_> …and lower level ones could be something else, or
> publishers define them
>
> <Karen_> …but others should be higher level
>
> <Karen_> …at some point digital publishing overtakes physical
> publishing
>
> <Karen_> …would be great to have terms that envisions those
>
> <Karen_> Markus: That is a very good point, Nick
>
> <Karen_> …it is the way we have been going
>
> <Karen_> …we look up the inheritance chain
>
> <Karen_> …most have a parent
>
> <Karen_> …to go up one step
>
> Markus - "We do need to take a step back and possibly do the
> more generic term. In the case of 'abstract' we need to look to
> see if there is a super-class or parent."
>
> Matt: "We need to be weary about saying 'lets just change a
> term' as that may not yield us the results we like."
>
> Markus: "have to consider things that are not tied to glossary
> definitions?"
> ... "To get to the first public working draft we need to have
> recorded consensus. As for doing call for consesus here, shoudl
> we do that now?"
> ... "It feels sudden to discuss now and just vote."
>
> <HeatherF> But this is still a working draft; as you said, it's
> still ok to have discussion topics
>
> Nick: "I'd like a week to review"
>
> <pkra> + for pushing it. we have a week, no? It also allows the
> minutes to this call to circulate.
>
> Ivan: "Ideally, the resolution should be taken on a meeting.
> It's perfectly fine if there is an e-mail discussion between
> now and next week and if the consesus is done via email. At
> this moment I'm very - I don't know how to handle it. I can
> understand that there might be a number of first-class
> application areas/things from web applications who are just as
> important - potentially in long term
>
> - may have the same name-clashing problems. "
>
> Ivan: "What I tried is putting the concerns that some people
> have in the PF working group. They could discuss with us via
> email as well."
> ...: "No need to wait for a week when we could have these
> issues/concerns properly written down and given to us so that
> we know what we have to answer to. Not only in general discuss
> but these are the problems."
>
> Charles: "It was mentioned that we don't want the 'role'
> attribute to say 'dpub-' which treats it as a second class
> citizen. What is the alternative?"
>
> markus: "The alternative is what we're proposing, where terms
> are there. A possible solution is similar to what ARIA has
> done, which is to limit definitions to avoid conflict."
> ...: "There are two ways to do it, hyphenated and RDFA. What
> we're saying is that we shouldn't do it for everything, but we
> should consider it for some."
> ... "It's complicated. There are pros and cons for everything.
> In XML there was so much fear of conflict that EVERYTHING
> became prefixed"
>
> Charles: "If we had something to define - at a global level -
> to say this is publishing, and everything below is for digital
> publishing..."
>
> Markus: "There is no such mechanism for roles today."
>
> Ivan: "That gets into religious debate... About roles being
> able to define profiles... HTML5 declared that to be a dead
> idea."
>
> <david_stroup> sorry need to drop...
>
> Bill: "Publishers do need definitions, and are using 'class' at
> the moment, so that they know what it is used for."
> ... "In the real world, people do use these terms and embed
> them in their concept."
>
> Markus: "Class is not the only term used, but it is very
> common."
>
> Packaging examples
>
> <mgylling>
> [11]https://www.w3.org/dpub/IG/wiki/OCF_Functionality
> ...: "Next up: Short FYI - Collection of use-cases called
> packaging. Overview of OCF added.".
> ..: "This new page lifts the functionality that OCF does. These
> are the functional hooks."
>
> [11] https://www.w3.org/dpub/IG/wiki/OCF_Functionality
>
> Ivan: "I went through the text sometime last weekend and there
> is one question for me that I don't have an answer - if you
> look at the epub-web and the reason for looking at packaging,
> it's relatively key to me that if we use the packaging format
> for web-packaging that we still need to add a super-structure
> to it for epub-web. Many things used and defined by epub that
> would migrate to a new
>
> environment. What I would like to understand is the difference
> between what zip gives me and what web-packaging gives. To
> compare what is comparable."
> ...: "Whether ZIP or web-packaging is the best for us is the
> question for which I don't have a reasonable answer."
>
> Markus: "We still need a fairly exhaustive list of use-cases,
> then we can start building these comparisons and see what is
> doable where."
>
> <mgylling>
> [12]http://www.w3.org/dpub/IG/wiki/UseCase_Directory#Packaging_
> and_Distribution
>
> [12] http://www.w3.org/dpub/IG/wiki/UseCase_Directory#Packaging_and_Distribution
>
> Ivan: "I did look at the use-cases that Tzviya put up there. I
> tried to see which could be used by either. That is what I'd
> like to see more of."
>
> Markus: "Simply put: Next step, once Tzviya - who owns the
> use-case collection - will be to start doing the comparison."
> ... "Anything more on Packaging?"
>
> F2F agenda
>
> <mgylling>
> [13]https://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_
> Details
>
> [13] https://www.w3.org/dpub/IG/wiki/May_2015_F2F_Logistics_and_Details
>
> Markus: "What we've done is to put the first ... together. If
> you go down to the schedule area, you'll see we have generous
> time sessions for packaging, identifiers, pagination and the
> re-charter."
>
> Nick: "We should discuss outreach/education at the meeting -
> maybe 30-45 minutes?"
>
> <ivan> +1
>
> <ivan> +10000 to Nick
>
> <Karen_> +1
>
> Markus: "What about STEM?"
> ...: "Stem at Face-2-face?"
>
> pkra : "I won't be there, but feel free to discuss."
>
> Makrus: "is there a topic you'd like us to be discussing?"
>
> pkra: "I'll have to think about it."
>
> Markus: "We'll finalize next monday. when we hear back from
> charles and deborah"
>
> identifiers
>
> <Bill_Kasdorf>
> [14]https://www.w3.org/dpub/IG/wiki/Task_Forces/identifiers#Ope
> n_Annotations_Fragment_Selector
>
> [14] https://www.w3.org/dpub/IG/wiki/Task_Forces/identifiers#Open_Annotations_Fragment_Selector
>
> Markus: "Next up Bill, updates on Identifiers."
>
> Bill: "We've had productive accumulation of information on the
> wiki. We have a candidate of specs to consider. [listed a bunch
> of identifier types]. Ivan added the open-annotations
> identifier, which I strongly support. I think philisophically
> aligning the fragment identifier with this annotations model
> makes all the sense in the world. the reason they are aligning
> with that is that it's
>
> extremely flexible and it defines a range, not a point. The
> other ones point to something that is already a defined thing -
> such as an element. This also allows you to associate a state
> with an identifier which is very helpful. it accomodates some
> of the others that have been defined. I'm not trying to force
> this on anyone, but I'd suggest you look at the options that we
> have and note there
>
> is a strong case to be made. It is not final though, originated
> by the open annotations working group."
> ...: "It's in a working draft. If we think this is the right
> way to go, we should state that we will align with the way the
> owrking group is doing the identifiers. it would be nice to
> keep this moving along but I won't be on the call next week, so
> not sure if this is something we need to do via e-mail, or am I
> being too quick to zero-in on the solution."
>
> Markus: "It is not clear to me how the open annotations
> document has. How can it be translated into a URI? There is no
> mapping of the concept to URI - at least not yet. For our
> purposes, it would be important for us to have that."
>
> <Bill_Kasdorf>
> [15]http://www.w3.org/TR/2014/WD-annotation-model-20141211/#fra
> gment-selector
>
> [15] http://www.w3.org/TR/2014/WD-annotation-model-20141211/#fragment-selector
>
> Bill: "The draft does provide a number of example URIs
> expressing fragments for a number of different use-cases"
>
> Ivan: "The point is that no, it does not give you a URI. It
> operates on a different environment because it would express
> the anchor in terms of an object with various attributes."
>
> <ivan> "selector": {
>
> <ivan> "@id": "[16]http://example.org/selector1",
>
> [16] http://example.org/selector1
>
> <ivan> "@type": "oa:DataPositionSelector",
>
> <ivan> "start": 4096,
>
> <ivan> "end": 4104
>
> <ivan> }
> ...: "So, that is how you define a range selector, but it's not
> a URI. In this sense it is different from the usual segments."
>
> <TimCole> +q
> ...: "That is a question we need to ask - is there a way to
> express those params as a URI"
>
> Tim: "My sense is that there hasn't been much - if any - sense
> of making that URI. It was defined to be an RDF solution. It's
> about creating a triple and using those triples to define a
> fragment."
> ...: "That said, a couple of these ideas were taking from
> different communities. so there may be other options/solutions
> to turning this into a URI fragment."
>
> Bill: "That was what I wanted to discuss: What are the next
> steps? Obviously we need to resolve this URI question. Do we
> need a spec that, before the annotations has the official spec.
> I'd prefer to align just with what they are doing. It would be
> nice to get a consensus that this is the direction we want to
> pursue."
>
> <Karen_> Nick: Does the URI standard have a character limit?
>
> <Karen_> Some browsers limit to 256
>
> <Karen_> Ivan: I don't recall
>
> <Bert> (No limit on URLs, AFAIK)
>
> <Karen_> Liam: A lot of current webapps would fail under that
>
> <Karen_> …used to be 72 limit
>
> <Karen_> Nick: I can tell you that Chrome will stop at 512
> characters
>
> <Karen_> …I have tried to use URL parameters for email
>
> <Karen_> …it ignores past 512
>
> <Karen_> …Firefox is similar
>
> <Karen_> Liam: Specific to mail or in general?
>
> <Karen_> Nick: I don't know; purely a bug and curiosity about
> breaking things
>
> <Karen_> …might make selector difficult
>
> <Karen_> …maybe shove into a URI
>
> <Karen_> Liam: A URI within a URI would have a limit
>
> <HeatherF> FWIW, "Microsoft Internet Explorer has a maximum
> uniform resource locator (URL) length of 2,083 characters.
> Internet Explorer also has a maximum path length of 2,048
> characters. This limit applies to both POST request and GET
> request URLs."
>
> <HeatherF> support.microsoft.com/en-us/kb/208427
>
> <Bert> (DNS names are limited to 256, I think, but URLS are
> not.)
>
> OK thank you all
>
> <HeatherF> That was just a quick web search
>
> <pkra> +1
>
> Markus: "With 1 minute - are there any contenders for items
> next week."
>
> <HeatherF> thanks, all
>
> Summary of Action Items
>
> [End of minutes]
> __________________________________________________________
>
>
> Minutes formatted by David Booth's [17]scribe.perl version
> 1.140 ([18]CVS log)
> $Date: 2015/04/13 16:50:13 $
>
> [17] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
> [18] http://dev.w3.org/cvsweb/2002/scribe/
>
>
Received on Tuesday, 14 April 2015 03:40:43 UTC